Enable Banking API

What authentication does the Enable Banking API use?

The specification declares an HTTP Bearer scheme with bearerFormat JWT, applied to every operation. The bearer is a JWT you sign yourself with RS256, using the private key behind the certificate you registered with Enable Banking. Its header carries kid set to your application id, its body carries iss enablebanking.com and aud api.enablebanking.com, and the maximum accepted time-to-live is 86400 seconds. Through Jentic the signing key stays inside your own self-hosted instance.

Can I initiate payments with the Enable Banking API?

Yes. POST /payments creates the payment and GET /payments/{payment_id} reports its status and details, so status polling is the recommended pattern. Cancellation is not exposed as an operation: the specification describes DELETE /payments/{payment_id} as 'Delete finished or failed payment', and the vendor reference documents the error PAYMENT_NOT_FINALIZED, 'You can not delete a payment that is not finalized or cancelled'.

How do I list supported European banks through Jentic?

Search Jentic for 'list European banks open banking', load the schema for GET /aspsps, and execute it. The response is the supported ASPSP directory, suitable for a bank-selection UI.

What are the rate limits for the Enable Banking API?

No quantitative rate limit is published. The vendor reference at https://enablebanking.com/docs/api/reference/ documents a 429 Too Many Requests response on every operation, so treat HTTP 429 as the throttling signal and back off. No numeric quota or threshold is stated there, and the specification behind this page declares no rate limit, so no figure is published here.

Can I delete a session when a user revokes access?

Yes. DELETE /sessions/{session_id} ends the session so subsequent calls with that session ID fail. This is the correct path when a user revokes consent in your app.

Is there an Enable Banking MCP server?

You do not need an MCP server to give your agent the Enable Banking API. Jentic connects it directly from the Jentic API Directory: import the API, register your Enable Banking application credential once with your self-hosted instance, and your agent calls the operations on demand without another server's tool definitions loaded into its context.

Can I limit what my agent is allowed to do with the Enable Banking API?

Yes, at operation level, and for account reads you can go narrower. The account id sits in the URL path on GET /accounts/{account_id}/details, GET /accounts/{account_id}/balances and GET /accounts/{account_id}/transactions, so a rule can pin the agent to one consented account. Payment creation works differently: POST /payments carries the ASPSP and the payment request in the body, so a rule there bounds the operation itself rather than a named creditor. A read-only agent is a rule that grants the GET operations and withholds POST /auth, POST /sessions, POST /payments, DELETE /payments/{payment_id} and DELETE /sessions/{session_id}.