Build a fully custom headless storefront - your own web app, mobile app, or POS - against a single OE Commerce store. Every endpoint below is namespaced under `/api/v1/store/...`. Building admin/back-office tooling instead? See [/docs/admin](/docs/admin). New here? [/guides/store](/guides/store) walks through getting a key, the anonymous cart session, and calling your first endpoints step by step - this page is the field-level reference to come back to afterward. ## Getting Started 1. Click the **Authorize** button at the top of this page. 2. Provide credentials: - **X-Commerce-Key** (always required) - your store's Store Access Key from Backoffice > Settings > Application APIs. `pk_store_...` (publishable) is safe for browser/mobile code; `sk_store_...` (secret) is server-to-server only and is rejected outright if a browser Origin header is present. - **Bearer** (only for endpoints acting on a specific customer - Account, Orders, Wishlists, etc.) - the token from **Auth > register** or **Auth > login**. Once authorized, you can explore and test all available endpoints directly from this interface. ## Anonymous Carts A guest cart is tracked by an `X-Session-Ref` header, not a cookie - the server generates one on your first request and echoes it back on every response after. Keep sending back whatever value you last received. Logging in carries that same cart forward onto the customer's account automatically, with no separate merge step. ## Errors Failures use RFC 9457 Problem Details (`application/problem+json`) with a stable `code` field for programmatic handling, e.g. `store_key_invalid`, `store_key_revoked`, `store_key_scope_denied`, `rate_limited`. A rejected *business* action (e.g. adding fewer than a product's minimum order quantity to the cart) instead comes back as HTTP 200 with `"success": false` and a human-readable `message` - always check `success` in the body, not just the HTTP status code. ## Rate Limits Requests are limited per Store Access Key (200/minute). The credential-stuffing surface (register/login/forgot-password/reset-password) is limited more tightly per caller IP (10 per 5 minutes). A 429 response includes a `Retry-After` header.

Go to Download

lockally/sdk

0 Favers
7 Downloads

The lockally control plane lets integrators and direct customers manage everything except actual mail data flow (which uses standard JMAP / IMAP / SMTP-submission against the data plane endpoints). **Authentication.** All `/v1/_*` endpoints require a Bearer API key in the `Authorization` header. Keys are formatted `lk_live__`. Generate the first key for a tenant via `cmd/seed`; subsequent keys via `POST /v1/api-keys`. **Errors.** Failures return [RFC 9457](https://www.rfc-editor.org/rfc/rfc9457) `application/problem+json` documents. **Scopes.** Each endpoint requires a specific scope on the presented key. Insufficient scope returns `403` with the required scope name in `detail`.

Go to Download

jooservices/laravel-controller

0 Favers
503 Downloads

Laravel API controller foundation for standardized JSON envelopes, RFC 7807 Problem Details, OpenAPI schemas, pagination, status checks, and custom formatters.

Go to Download

isaidgitmenow/laravel-errors

1 Favers
1 Downloads

Cure your Laravel exception handling headaches. Manage errors, rate limits, and API responses using clean, declarative PHP 8.4 attributes.

Go to Download

bank-io/bankio-sdk-php

1 Favers
106 Downloads

# Summary The **NextGenPSD2** *Framework Version 1.3.6* (with errata) offers a modern, open, harmonised and interoperable set of Application Programming Interfaces (APIs) as the safest and most efficient way to provide data securely. The NextGenPSD2 Framework reduces XS2A complexity and costs, addresses the problem of multiple competing standards in Europe and, aligned with the goals of the Euro Retail Payments Board, enables European banking customers to benefit from innovative products and services ('Banking as a Service') by granting TPPs safe and secure (authenticated and authorised) access to their bank accounts and financial data. The possible Approaches are: * Redirect SCA Approach * OAuth SCA Approach * Decoupled SCA Approach * Embedded SCA Approach without SCA method * Embedded SCA Approach with only one SCA method available * Embedded SCA Approach with Selection of a SCA method Not every message defined in this API definition is necessary for all approaches. Furthermore this API definition does not differ between methods which are mandatory, conditional, or optional. Therefore for a particular implementation of a Berlin Group PSD2 compliant API it is only necessary to support a certain subset of the methods defined in this API definition. **Please have a look at the implementation guidelines if you are not sure which message has to be used for the approach you are going to use.** ## Some General Remarks Related to this version of the OpenAPI Specification: * **This API definition is based on the Implementation Guidelines of the Berlin Group PSD2 API.** It is not a replacement in any sense. The main specification is (at the moment) always the Implementation Guidelines of the Berlin Group PSD2 API. * **This API definition contains the REST-API for requests from the PISP to the ASPSP.** * **This API definition contains the messages for all different approaches defined in the Implementation Guidelines.** * According to the OpenAPI-Specification [https://github.com/OAI/OpenAPI-Specification/blob/master/versions/3.0.1.md] "If in is "header" and the name field is "Accept", "Content-Type" or "Authorization", the parameter definition SHALL be ignored." The element "Accept" will not be defined in this file at any place. The elements "Content-Type" and "Authorization" are implicitly defined by the OpenApi tags "content" and "security". * There are several predefined types which might occur in payment initiation messages, but are not used in the standard JSON messages in the Implementation Guidelines. Therefore they are not used in the corresponding messages in this file either. We added them for the convenience of the user. If there is a payment product, which needs these fields, one can easily use the predefined types. But the ASPSP need not to accept them in general. * **We omit the definition of all standard HTTP header elements (mandatory/optional/conditional) except they are mentioned in the Implementation Guidelines.** Therefore the implementer might add these in his own realisation of a PSD2 comlient API in addition to the elements defined in this file. ## General Remarks on Data Types The Berlin Group definition of UTF-8 strings in context of the PSD2 API has to support at least the following characters a b c d e f g h i j k l m n o p q r s t u v w x y z A B C D E F G H I J K L M N O P Q R S T U V W X Y Z 0 1 2 3 4 5 6 7 8 9 / - ? : ( ) . , ' + Space

Go to Download