Base URLs & Request Format
Base URLs
| Environment | URL | Use Case |
|---|---|---|
| Production | https://api.inflowpay.com | Live transactions |
| Sandbox | https://sandbox.api.inflowpay.com | Integration testing — request access from Inflow |
| Card Payments | https://api-card.inflowpay.com | Optional PCI-scoped host for server-to-server card capture only (POST /api/server/payment) |
api-card.inflowpay.comis a separate base URL documented on the server-to-server payment endpoints in the API reference — use it only when your backend sends raw card data to Inflow. Hosted checkout (POST /api/payment), balance, payouts, Connect, and webhooks use the standard API host (api.inflowpay.com/sandbox.api.inflowpay.com). If you use the Inflow SDK for cards, keep the default API URL.
Sandbox: use
https://sandbox.api.inflowpay.comwith sandbox keys. See Sandbox Environment for access and key prefixes.
URL Prefixes by Resource
Note: Subscription endpoints use a different path prefix than payment endpoints.
| Resource | Example Path |
|---|---|
| Payments (hosted checkout) | https://api.inflowpay.com/api/payment |
| Balance | https://api.inflowpay.com/api/balance |
| Account behind a key | https://api.inflowpay.com/api/me |
| Webhooks | https://api.inflowpay.com/api/webhook |
| Subscriptions | https://api.inflowpay.com/subscription/... (no /api/ prefix) |
| Payment links | https://api.inflowpay.com/api/link |
Identify the Account Behind a Key
GET /api/me returns the id of the Inflow account that owns the API key making the request, and nothing else. Use it when your platform connects several Inflow accounts and needs to tell them apart, for example to refuse connecting the same account to two of your customers. A sandbox key returns the sandbox account id. The X-On-Behalf-Of header is ignored on this endpoint: the id is always the key owner's.
curl https://api.inflowpay.com/api/me \
-H "Accept: application/json" \
-H "X-Inflow-Api-Key: inflow_prod_your_key"{
"userId": "usr_AbCdEfGhIjKlMnOpQrStU"
}Request Format
All API requests use JSON for both request and response bodies.
Headers
| Header | Required | Description |
|---|---|---|
Content-Type | Yes (for POST/PUT/PATCH) | Always application/json |
Accept | Recommended | application/json |
X-Inflow-Api-Key | Yes | Your private API key |
Example Request
curl -X POST https://api.inflowpay.com/api/payment \
-H "Content-Type: application/json" \
-H "Accept: application/json" \
-H "X-Inflow-Api-Key: inflow_prod_your_key" \
-d '{
"products": [{ "name": "Product", "price": 4999, "quantity": 1 }],
"currency": "EUR",
"customerEmail": "[email protected]",
"successUrl": "https://yoursite.com/success",
"cancelUrl": "https://yoursite.com/cancel"
}'Example Response
{
"paymentId": "pay_abc123",
"purchaseUrl": "https://checkout.inflowpay.com/pay/pay_abc123"
}HTTP Methods
| Method | Usage |
|---|---|
GET | Retrieve resources (payments, subscriptions, links) |
POST | Create resources or perform actions |
PATCH | Partially update a resource |
PUT | Fully update a resource |
DELETE | Delete a resource or cancel a subscription |
HTTP Status Codes
| Code | Meaning |
|---|---|
200 | Success (GET, PATCH, PUT, DELETE) |
201 | Created (POST) |
400 | Bad Request — Invalid parameters |
401 | Unauthorized — Invalid or missing API key |
404 | Not Found — Resource doesn't exist |
500 | Internal Server Error — Something went wrong on our side |
Error Response Format
All errors return a consistent JSON structure:
{
"statusCode": 400,
"message": "Validation failed",
"error": "Bad Request"
}For validation errors, message may be an array of error strings:
{
"statusCode": 400,
"message": [
"currency must be one of the following values: EUR, USD",
"customerEmail must be an email"
],
"error": "Bad Request"
}Updated 10 days ago
