> ## Documentation Index > Fetch the complete documentation index at: https://docs.meld.io/llms.txt > Use this file to discover all available pages before exploring further. # Reference This page is a quick reference for environments, authentication, status codes, errors, security, and date formats. It is for developers who have already started integrating Meld and need to look up exact values while coding. If you have not started the integration process, you should skip this page and start with the [Overview](/docs/welcome/overview). # Meld Environments Meld offers both production and sandbox environments. The below table contains the URL for each environment: | Environment | API Base URL | | :---------- | :----------------------------------------------- | | Sandbox | [https://api-sb.meld.io](https://api-sb.meld.io) | | Production | [https://api.meld.io](https://api.meld.io) | Sandbox and Production use separate API keys and separate data. A key issued for one environment will not work against the other. Test transactions in Sandbox do not move real funds. To obtain your API key for either Production or Sandbox environments, work with your Meld contact. Your API Key is a secret, treat it as such. Do not share it or send it through a front end call. # Authentication Meld uses API keys to authenticate requests. These keys carry many privileges such as authorizing payments and accessing financial accounts data. It is important to keep them private and secure during both storage and transmission. Authentication is handled via HTTP headers, using the `Authorization` header. Example request: ```bash theme={null} curl --location --request \ GET 'https://api.meld.io/' \ --header 'Authorization: BASIC {{Your API Key}}' ``` Example successful response: ```json theme={null} { "id": "abc123", "status": "OK" } ``` "BASIC" Authorization When submitting your API key for authentication, you must specify "BASIC " before the key value pair. Note the trailing space between `BASIC` and your key. To help keep your API keys secure, follow these best practices: * Do not embed API keys directly in code, because they can be accidentally exposed to the public. Instead, store them in environment variables or in files outside of your application's source tree. * Do not store your API keys in files inside your application's source tree. If you must store API keys in files, keep the files outside your source tree to ensure your keys do not end up in your source code control system, especially if you use a public one such as GitHub. * Delete unneeded API keys to minimize exposure to attacks. * Review your code before publicly releasing it. Ensure that it does not contain API keys or any other private information before you make it publicly available. # API Status Codes The following table lists the status code you will receive from our APIs.
Status code Description
200 Successful, with response data as defined by the `Content-Type` header
201 Successful, with response data as defined by the `Content-Type` header
400 Bad Request
401 Unauthorized
403 Forbidden
404 No Resource Found
422 Input Validation Failed
425 Failure. TOO\_EARLY You might see this error when the same idempotent key is used twice and the first transaction is still being processed.
429 Too Many Requests
500 Unexpected Issue

# API Error Schema Any status code of `400` or higher returns an error payload. Inspect the `code` and `errors` fields to determine how to handle the failure, and surface `requestId` when contacting Meld support so we can trace the exact call. All errors are returned in the form of JSON and contain the following data: | Key | Description | | :---------- | :-------------------------------------------------------------------------------------------------------------------- | | `code` | A categorization of the error | | `message` | A developer-friendly representation of the error code. This may change over time and is not safe for programmatic use | | `errors` | A user-friendly representation of the error code. This may change over time and is not safe for programmatic use. | | `requestId` | The request Id | | `timestamp` | The date and time when the request was made | Below is a sample error response: ```json theme={null} { "code": "BAD_REQUEST", "message": "Bad request", "errors": [ "[amount] Must be a decimal value greater than zero" ], "requestId": "eb6aaa76bd7103cf6c5b090610c31913", "timestamp": "2022-01-19T20:32:30.784928Z" } ``` # Security 1. CORS -- Meld does not need to whitelist any of our customer's URL or IPs for them to call our public Production & Sandbox APIs. You can use whichever URL you desire, as we authenticate via your Meld API Key. 2. For security reasons, Meld recommends using your backend server to make the calls to Meld's API. If you make these calls from your frontend instead, it may not work and you may get back a CORS error. This is because making calls to Meld APIs requires that you pass in an `Authorization` header with the API Key we issued you. It is insecure to keep this API Key hardcoded in your mobile app or web app. 3. All our customers need to treat the Meld API Key they've been issued like any other password. It is an extremely sensitive credential that needs to be protected at all cost. The security measures you need to ensure are: a) strict controls to the backend server (as it has access to your Meld API Key), b) a way to authenticate your FE/app to your backend server, c) reject/ignore all other calls to your backend server. Never call Meld APIs directly from a browser, mobile app, or any other untrusted client. Calls must originate from your backend server so your API key is never exposed. # Dates All Meld dates and timestamps returned via Meld's API are in UTC time and formatted using ISO 8601 (for example, `2022-01-19T20:32:30.784928Z`).