> ## Documentation Index > Fetch the complete documentation index at: https://docs.matambaintelligence.com/llms.txt > Use this file to discover all available pages before exploring further. # Get access and support > How to reach us, what to send for each request, and what to do when a key or a signing secret leaks. Some steps need our action: we issue keys, register webhook endpoints and IP addresses, set limits and credit your wallet. This page says what to send for each, so we can act on your first message. ## How to reach us Email [partners@matambaintelligence.com](mailto:partners@matambaintelligence.com). We read it from 9:00 to 17:00 West Africa Time (WAT), Monday to Friday, and a message sent outside those hours is read at the start of the next business day. We reply within one business day. Send the details the table below lists for your request. Never send a whole API key or a signing secret. The last four characters of a key are enough for us to find it. ### How keys and secrets reach you We give you each API key and each webhook signing secret once, through a one-time link we send to your technical contact. The link opens once. Store what it shows in your secrets manager: we can't show it again. ### Urgent problems and incidents For a problem that stops live trading during [market hours](/orders#trading-hours), put URGENT at the start of the subject. We read those first. When an incident affects the API, we email your technical contact, and again when it's resolved. There's no status page yet. When our operations team pauses trading, new orders, applications and allocations get [`503 trading_paused`](/errors#trading_paused) until we resume, while cancels and reads still work. We email your technical contact when we pause and again when we resume. ## If a key leaks Revoke it yourself, at once. This works at any hour, from any address, and whatever the key's scopes. The request revokes the key it's sent with. Send the request to the key's own host: a live key to the live host. Sent to the other host, it returns `401 unauthorized`, and nothing is revoked. ```http Request theme={"dark"} POST /v1/keys/revoke Authorization: Bearer $KEY ``` ```bash cURL theme={"dark"} curl -X POST https://$HOST/v1/keys/revoke \ -H "Authorization: Bearer $KEY" ``` ```http Response theme={"dark"} HTTP/1.1 204 No Content ``` The key stops working on its next request, and your other keys keep working. The answer is the same whether or not the key still worked, so it never tells anyone a key is real. To check, send any request with the key from one of your servers: `401 unauthorized` means it is revoked. Then email [partners@matambaintelligence.com](mailto:partners@matambaintelligence.com) with the key's environment (sandbox or live) and its last four characters, and we issue you a new key during support hours. Don't rotate a leaked key. Rotation keeps the old key working through the overlap. Hold a second live key in reserve, issued for the same addresses and scopes. If you revoke one at night or at a weekend, you keep trading with the other until we issue its replacement. ## If a signing secret leaks Email [partners@matambaintelligence.com](mailto:partners@matambaintelligence.com) with URGENT at the start of the subject, and the environment. We rotate the secret with no overlap, so the old secret stops signing at once, and send you the new one. Our rotation changes only the secret we sign with. Until your endpoint stops accepting the old secret, anyone holding it can sign an event your endpoint accepts, so remove it from your verifier at once. Until the new secret reaches you, don't act on a webhook alone: find its `id` in [`GET /v1/events`](/webhooks#catch-up-on-missed-events), which only your API key can read, and act on what the list returns. Between our rotation and your switch to the new secret, your endpoint can't verify our events. Refuse them, and we retry each one on the [retry schedule](/webhooks#retries). ## What to send for each request | You need | What we need | You get back | | -------------------------------------------------------------------------------------- | -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | Sandbox access | Your company's name, a technical contact (a name and an email address) for our notices, and the [scopes](/keys-and-security#scopes) each key needs if not all four. | What the quickstart's [Before you begin](/quickstart#before-you-begin) lists. | | More sandbox test money | The amount. | A `credit` to your sandbox wallet, in `GET /v1/wallet/transfers`. | | A sandbox account ending in `98` | Nothing else. | An account whose balance, estimates and orders meet the settlement lockout. See [Test values](/sandbox#test-values). | | A webhook endpoint | The environment, and a URL that meets [the rules](/webhooks#register-your-endpoint). | Its signing secret, and the IP address we send events from. | | A new webhook URL | The environment and the new URL. | Confirmation. Your secret stays the same. | | A new signing secret | The environment. | A new secret. See [Rotate your secret](/webhooks#rotate-your-secret). For a leaked secret, see [If a signing secret leaks](/support#if-a-signing-secret-leaks). | | Events sent again | The environment, and the earliest change to resend, as a time with its time zone, such as `2026-09-25T06:00:00+01:00`. | Every event we stopped retrying for a change at or after that time, sent again with the same `webhook-id`. Events we're still retrying aren't affected, and an event no longer in `GET /v1/events` can't be resent. See [Retries](/webhooks#retries). | | Live access | Our agreement with your company, which your contact at Matamba arranges. Then each IP address or range your servers send requests from, following [the rules](/keys-and-security#live-keys-and-ip-addresses), and the scopes each key needs. | Within one business day of having all three: the live host, a live key, the bank details and your payer reference for paying into your wallet, and whether account opening and deposits are enabled in live. See [Fund an account](/funding). | | A standby live key | The same addresses and scopes as your live key. | A second live key to keep in reserve. See [If a key leaks](/support#if-a-key-leaks). | | A new technical contact | Their name and email address. | Confirmation. Our notices go to them from then on. | | Different IP addresses for live | Every address or range the key should work from, and the current key's last four characters. A key's addresses are fixed when we issue it. | A new live key for those addresses. [Tell us](/support#how-to-reach-us) when you've switched, and we revoke the old one. | | A key rotation | The key's environment and last four characters, and the overlap you need. See [Rotate a key](/keys-and-security#rotate-a-key). | A new key with the same addresses and scopes. | | A different limit | Which [limit](/limits), and the value you need. | Confirmation. `GET /v1/limits` then shows it. | | A payment missing from your wallet | Its date, its amount and the bank's reference: for an instant transfer, its session ID. See [Fund an account](/funding#2-find-the-credit). | What happened to it. | | Money out of an account | What [Take money out](/wallet#take-money-out) lists, from your technical contact's address. | Confirmation by reply, then payment within two business days of the request. | | A change to a customer's details, an account closed, or shares moved to another broker | The account code and what you need, without the customer's personal details. These aren't in the API yet. | We take it to the broker, and reply with what it needs from you. | ## Report a problem When a request fails in a way the [error reference](/errors) doesn't explain, or an order, application or allocation doesn't resolve, [send us](/support#how-to-reach-us): * the `x-request-id` header of the response, * the time of the request, with its time zone, * the method and path, such as `POST /v1/orders`, * the `error.code`, if there was one, * the `id` of the order, application or allocation, if there is one. Don't send your customers' personal details, such as a name, a BVN or a phone number. We don't store them, so they don't help us trace a request. ## Found a mistake in these pages? Email [partners@matambaintelligence.com](mailto:partners@matambaintelligence.com) with the page and what's wrong or missing.