GuidesAPI RefFAQsBlog
API Ref
StatusSupport

API Initialization

API Reference Pages

About the API

This version of the API is architected around REST using standard HTTP verbs to communicate and HTTP response codes to indicate status and errors. All responses come in standard JSON.

🚧

Additional Fields

On occasion, you may see fields in the API responses that are not listed in our examples. These fields are for our testing purposes only and may or may not become permanent in the future. We recommend that you do not rely on these fields for your integration until you see them listed in our API documentation.

Host URLs

EnvironmentURL
Sandboxhttps://uat-api.synapsefi.com/v3.1
Productionhttps://api.synapsefi.com/v3.1

Request Headers

Key ‌‌  ‌‌  ‌‌ ‌‌  ‌‌  ‌‌  ‌‌  ‌‌  ‌‌  ‌‌ ‌‌  ‌‌  ‌‌ ‌‌  ‌‌  ‌‌  ‌‌  ‌‌  ‌‌  ‌‌Value ‌‌  ‌‌  ‌‌ ‌‌  ‌‌  ‌‌  ‌‌  ‌‌  ‌‌  ‌‌ ‌‌  ‌‌  ‌‌ ‌‌  ‌‌  ‌‌  ‌‌  ‌‌  ‌‌  ‌‌ ‌‌  ‌‌  ‌‌ ‌‌  ‌‌  ‌‌  ‌‌  ‌‌  ‌‌  ‌‌Description
X-SP-GATEWAYCLIENT_ID|CLIENT_SECRET[Required] This is your client_id and client_secret separated by a vertical bar.
X-SP-USER-IPUSER_IP_ADDRESS[Conditionally Required] The ip_address of the user.
X-SP-USERUSER_OAUTH_KEY|USER_FINGERPRINT[Conditionally Required] User’s oauth_key and fingerprint separated by a vertical bar.
Content-Typeapplication/json[Required]
X-SP-IDEMPOTENCY-KEYIDEMPOTENCY_KEYOptional. POST calls only.

Example Request Headers

Host: uat-api.synapsefi.com
X-SP-GATEWAY: client_id_2bb1e412edd311e6bd04e285d6015267|client_secret_6zZVr8biuqGkyo9IxMO5jY2QlSp0nmD4EBAgKcJW
X-SP-USER-IP: 127.0.0.1
X-SP-USER: |e83cf6ddcf778e37bfe3d48fc78a6502062fc
Content-Type: application/json

Please note in the example above that for the X-SP-USER header only the fingerprint (e83cf6ddcf778e37bfe3d48fc78a6502062fc) is provided, proceeded by a pipe (|) character (as opposed to both the user OAuth key and the user fingerprint), which would be the case when, for instance, creating a new user.

📘

Idempotent Requests

POST calls support idempotency for safely retrying requests without accidentally performing the same operation twice. For example, if a request to create a transaction fails due to a network connection error, you can retry the request with the same idempotency_key to guarantee that only a single transaction is created.

Idempotency keys expire after 24 hours.