Authentication
Every request to the Connect API carries an API key as a bearer token. Keys are created in the portal and scoped to your account's own connected accounts.
The bearer scheme
Send your key in the Authorization header on every request:
Authorization: Bearer edk_a1B2c3D4_EXAMPLEexampleEXAMPLEexampleEXAMPLEexample1A complete request looks like this:
curl https://api.endute.com/v1/accounts \
-H "Authorization: Bearer edk_a1B2c3D4_EXAMPLEexampleEXAMPLEexampleEXAMPLEexample1"There is no OAuth flow and no session. The key is the single credential, so treat it as a secret.
Key format
Every key begins with the edk_ prefix (Endute Connect key) and matches this fixed pattern:
edk_[A-Za-z0-9_-]{8}_[A-Za-z0-9_-]{43}That is the literal edk_, an eight-character segment, an underscore, then a forty-three-character segment, all from the URL-safe alphabet A–Z a–z 0–9 _ -. The first twelve characters (edk_ plus the first eight) are the key's display prefix, shown in the portal so you can identify a key without seeing its secret.
Key lifecycle
- Create a key in the portal. The full secret is returned exactly once, at creation. We store only its SHA-256 hash, so we cannot show it again and a database leak exposes no usable secret.
- Rotate by creating a new key, switching your integration to it, then revoking the old one. There is no separate rotate action: rotation is create-then-revoke.
- Revoke a key in the portal at any time. A revoked key stops working immediately and returns
invalid_api_key. Revoked keys stay listed for audit with their revocation date.
Multiple keys
Who can use the API
A key authenticates, but entitlement decides whether it can serve data. The rules:
- Connect accounts are entitled while their status is
sandboxoractive. The free sandbox tier is fully usable; connecting a real bank moves you toactiveonce billing is set up. - Existing Endute app subscribers are entitled while their subscription is
activeortrialing(API access is included with the app plan). - Anything else, such as a lapsed subscription, returns a
403withsubscription_lapsed. The key is not revoked, so access resumes automatically on renewal.
Error responses
Authentication and entitlement failures use the standard error envelope with a machine-readable code you can branch on:
{
"error": {
"code": "invalid_api_key",
"message": "Invalid or revoked API key."
}
}{
"error": {
"code": "subscription_lapsed",
"message": "Your subscription has lapsed. API access resumes when it is renewed."
}
}| Code | HTTP | Meaning |
|---|---|---|
| not_authenticated | 401 | No Authorization header was sent. |
| invalid_api_key | 401 | The header was malformed, or the key is unknown or revoked. |
| user_inactive | 401 | The account that owns the key is disabled. |
| subscription_lapsed | 403 | The key is valid but the subscription is not currently entitled. Renew to resume; the key is not revoked. |
| demo_account | 403 | Demo accounts cannot use the API. |
| connect_not_available | 403 | Endute Connect is not currently available for this account. |
See Pagination & errors for the full envelope and throttling behaviour.
Scanning for leaked keys
Because keys have a fixed shape, you can scan your own code, logs and history for accidental exposure. The pattern to search for is:
edk_[A-Za-z0-9_-]{8}_[A-Za-z0-9_-]{43}If you find a leaked key, revoke it in the portal immediately and create a replacement. If you believe a key has been used by someone else, revoke it and contact us so we can help review the usage window.
