Download OpenAPI specification:
This is full API documentation of BluAi testing API.
Getting the status of the testing API with some environment info, It can be used during the sanity testing on production to assure that the API isn't accessible
{- "data": {
- "status": "string",
- "server_time": "string"
}
}Registers a fake user (member) under the given partner for testing purposes. Only the partner code is required; every other member detail is generated or defaulted automatically — a name, a gender, a unique email, a mobile number on the partner's default country calling code, and a member reference number (persisted prefixed with the partner's prefix). The member is created with its email and mobile verified and is attached to the partner's default segment. Every one of those values can be overridden, and either verification flag switched off, through the optional parameters below; an omitted, null or empty parameter falls back to its default. The returned user_id can then be passed to the generate-access-token endpoint to obtain an access token for that user.
| partner_code required | string Code of the partner to register the member under. |
| first_name | string or null <= 255 characters Default: "Test" Member's first name. |
| last_name | string or null <= 255 characters Default: "User" Member's last name. |
string or null <email> <= 255 characters Member's email address. Defaults to a generated unique | |
| gender | string or null Default: "m" Enum: "m" "f" "o" Member's gender. Also drives the member's derived title. An unrecognised value is rejected rather than defaulted. |
| reference | string or null <= 200 characters Member reference number to use instead of a generated one. It is persisted prefixed with the upper-cased partner prefix, e.g. prefix |
| mobile | string or null <= 20 characters National mobile number to use instead of a generated one, without the country calling code. |
| mobile_code | string or null <= 10 characters Country calling code for the mobile number. Defaults to the telephone code of the partner's default country, and is required when the partner has none. |
| email_verified | boolean Default: true Whether the registered member's email ends up verified. |
| mobile_verified | boolean Default: true Whether the registered member's mobile ends up verified. |
| segment_mapping_ids | Array of strings or null[ items <= 32 characters ] Mapping ids of the partner segments to attach the member to. Defaults to the partner's default segment (the one carrying no attributes); an empty list is returned when the partner has no such segment. When supplied, these segments replace the default rather than adding to it, so the member ends up in exactly the segments listed here. |
{- "partner_code": "alinma",
- "first_name": "Test",
- "last_name": "User",
- "email": "test-user-66c9f1a2b3c4d@example.com",
- "gender": "m",
- "reference": "1786343859437",
- "mobile": "512345678",
- "mobile_code": "+966",
- "email_verified": true,
- "mobile_verified": true,
- "segment_mapping_ids": [
- "GOLD"
]
}{- "user_id": 555,
- "partner_code": "alinma",
- "first_name": "Test",
- "last_name": "User",
- "gender": "m",
- "email": "test-user-66c9f1a2b3c4d@example.com",
- "reference": "ALM-1786343859437123",
- "telephone_code": "+966",
- "mobile": "512345678",
- "email_verified": true,
- "mobile_verified": true,
- "segment_ids": [
- 1234
]
}Generates a bearer token for a user to be used when calling the (auth-protected) User API. The shape of the returned token depends on how the partner authenticates User API requests for the client type behind the api-key the User API will be called with, which the caller declares through client_code:
client_code=backend) receive the user's reference / user code, which the User API
matches against the stored reference number. The user code is created on demand if the
user does not already have one.
The same partner can return both shapes: Alinma authenticates its backend api-keys by user code while its web and mobile api-keys still use JWTs, so pass the client_code matching the api-key you will send to the User API. Either way the value is passed verbatim as the Authorization: Bearer token.| user_id required | string |
| partner_code required | string Code of an active (non-draft) partner. Draft partners are rejected — they have no resolvable tenant configuration. |
| client_code required | string Enum: "web" "android" "ios" "backend" The client the token is issued for — use the one matching the client type of the api-key the User API will be called with ( |
{- "user_id": "string",
- "partner_code": "string",
- "client_code": "web"
}{- "access_token": "string"
}Generating an API access token of an admin
| admin_id required | integer |
{- "admin_id": 0
}{- "data": {
- "access_token": "string"
}
}| reference required | string |
| private_key | string |
| wrap_public_key | string |
| partner_id | integer |
| raw | boolean |
| login | boolean |
{- "reference": "string",
- "private_key": "string",
- "wrap_public_key": "string",
- "partner_id": 0,
- "raw": true,
- "login": true
}"string"It imports transactions from transaction_stage_data at the same predefined point in time to simulate concurrent import transactions (multiple threads), you send multiple requests each with a different date and set execution_time=Y-m-d H:i:s (max 5 minutes from the current time GMT). when all the requests reach that point in time they'll be executed concurrently (motivation BP-18740)
| partner_id required | integer |
| date required | string <date> |
| execution_time required | string <date-time> GMT time (max 5 minutes from the current time) |
{- "partner_id": 0,
- "date": "2022-12-06",
- "execution_time": "2023-07-14 07:11:00"
}"string"Rewards a fixed number of loyalty points to an existing member for testing purposes. Unlike the Admin API equivalent, this endpoint only requires the partner code, the member id, and the points amount; the network, country, transaction date and description are derived automatically. The transaction is booked against the partner's default store and that store's default point of sale, and the points expire according to the partner's default point expiration rule (no expiry when the partner has none configured). Negative points trigger a reward reversal. Rewarding a closed member is rejected.
| partner_code required | string Code of the partner the member belongs to |
| member_id required | integer Id of the member to reward |
| points required | integer [ -99999999 .. 99999999 ] Points to reward (negative values reverse a previous reward) |
{- "partner_code": "string",
- "member_id": 0,
- "points": -99999999
}{- "member_id": 0,
- "points": 0,
- "transaction_id": 0
}Redeems a fixed number of loyalty points from an existing member for testing purposes. Unlike the Admin API equivalent, this endpoint only requires the partner code, the member id, and the points amount; the store, currency and description are derived automatically and the redemption is always expressed in points. The transaction is booked against the partner's default store and that store's default point of sale. The member must already hold enough balance (e.g. credited via the reward-points endpoint), otherwise the redemption is rejected.
| partner_code required | string Code of the partner the member belongs to |
| member_id required | integer Id of the member to redeem from |
| points required | integer >= 1 Points to redeem |
{- "partner_code": "string",
- "member_id": 0,
- "points": 1
}{- "member_id": 0,
- "points": 0,
- "message": "Points redeemed successfully."
}It can be used to send an order's emails by using only its id rather than going through the redemption flow from the beginning
string Enum: "yes" "no" Whether to run queued jobs asynchronously or not |
| order_id required | integer |
| debug_email_labels | integer Enum: 0 1 |
{- "order_id": 0,
- "debug_email_labels": 0
}{ }Send rewarding-transaction emails to a specific email with the ability to select the target (admin, client, gifter, receiver)
| transaction_id | integer |
| order_id | integer |
| mail_to required | string <email> |
| target required | string Enum: "admin" "client" "gifter" "receiver" |
| lang | string Enum: "en" "ar" |
| debug_email_labels | integer Enum: 0 1 |
{- "transaction_id": 0,
- "order_id": 0,
- "mail_to": "user@example.com",
- "target": "admin",
- "lang": "en",
- "debug_email_labels": 0
}"string"| estatement_id required | integer |
| user_id | integer |
| partner_id | integer |
| mail_to | string <email> |
| mail_from | string <email> |
{- "estatement_id": 0,
- "user_id": 0,
- "partner_id": 0,
- "mail_to": "user@example.com",
- "mail_from": "user@example.com"
}{ }It can be used to check HTML content of the order emails
| order_id required | integer |
| lang | string Enum: "en" "ar" "fr" |
{- "order_id": 0,
- "lang": "en"
}{- "subject": "Email Subject",
- "html": "<html>...</html>"
}It can be used to send an order's sms by using only its id rather than going through the redemption flow from the beginning. The order should be in approved status
string Enum: "yes" "no" Whether to run queued jobs asynchronously or not |
| order_id required | integer |
{- "order_id": 0
}{ }It can be used to send an order's sms by using only its id rather than going through the redemption flow from the beginning.
string Enum: "yes" "no" Whether to run queued jobs asynchronously or not |
| order_id required | integer |
{- "order_id": 0
}{ }| partner_code required | string |
| date required | string |
| user_id | number |
{- "partner_code": "string",
- "date": "string",
- "user_id": 0
}{ }| queues | string Comma-separated list of queue names |
| jobs_per_queue | numeric |
{- "queues": "string",
- "jobs_per_queue": null
}{ }View a list of SMS mocks
| mobile_number required | string Mobile number |
| batch required | integer Batch |
{- "mobile_number": "+96555432998",
- "batch": 6154
}{- "data": [
- {
- "id": 379614,
- "number": "+243754356",
- "otp": "3648",
- "message": "3648 is your OTP. Please use it to proceed. For security reasons do not disclose this OTP to any third party.",
- "batch": "5147",
- "created_at": "2024-04-20 04:40:57",
- "updated_at": "2024-04-20 04:40:57"
}
]
}Returns a failure response for testing webhook error handling
| property name* additional property | any |
{ }{- "success": false,
- "error": "server internal error"
}Returns a success response for testing webhook success handling
| property name* additional property | any |
{ }{- "success": true
}Returns a random response (80% failure, 20% success) for testing webhook reliability handling
| property name* additional property | any |
{ }{- "success": true
}Clears throttle counters for the given identifiers. At least one of ip, identifier, partner_code, or user_id is required.
Named limiters — admin and user flow routes. Keyed by ip or identifier value. Cleared when ip or identifier is provided. Use the limiters array to target a specific subset.
Identifier-based throttle — user-facing auth routes (/v7/auth/flows, /v7/flows/authentication). Keyed by identifier value. Cleared when identifier is provided.
Partner throttle (production only) — marketplace item routes. Keyed by partner code. Cleared when partner_code is provided.
User throttle — /v7/email-verification/tokens. Keyed by user ID. Cleared when user_id is provided.
Admin login blocked (by login value and/or IP)
{ "identifier": "admin", "ip": "116.203.224.45", "limiters": ["admin-auth-flow"] }
Admin password reset email blocked
{ "identifier": "admin@example.com", "ip": "116.203.224.45", "limiters": ["admin-reset-password-email"] }
Admin password reset blocked
{ "ip": "116.203.224.45", "limiters": ["admin-reset-password"] }
Admin API write blocked
{ "ip": "116.203.224.45", "limiters": ["admin-api-write"] }
Horizon invalid credentials blocked
{ "ip": "116.203.224.45", "limiters": ["horizon-invalid-credentials"] }
User auth flow blocked by identifier
{ "identifier": "user@example.com" }
User auth flow blocked by IP
{ "ip": "116.203.224.45", "limiters": ["user-auth-flow"] }
User auth flow blocked by both — clear everything at once
{ "identifier": "user@example.com", "ip": "116.203.224.45", "limiters": ["user-auth-flow"] }
Note: omitting limiters clears ALL named limiters for that ip/identifier, including admin ones. Use limiters to scope the reset.
User password reset flow blocked
{ "ip": "116.203.224.45", "limiters": ["user-password-reset-flow"] }
User password update flow blocked
{ "ip": "116.203.224.45", "limiters": ["user-password-update-flow"] }
User profile update flow blocked
{ "ip": "116.203.224.45", "limiters": ["user-profile-update-flow"] }
User email verification blocked
{ "user_id": 12345 }
Marketplace partner throttle blocked (production only)
{ "partner_code": "PARTNER01" }
Clear everything for an IP and identifier at once
{ "identifier": "user@example.com", "ip": "116.203.224.45" }
| ip | string IP address — clears all named limiters keyed by IP (or the subset specified in limiters) |
| identifier | string Login, email, or mobile — clears named limiters keyed by this value AND the identifier-based throttle |
| partner_code | string Partner code — clears the partner throttle (production only) |
| user_id | integer User ID — clears the user throttle |
| limiters | Array of strings Items Enum: "admin-reset-password-email" "admin-reset-password" "admin-auth-flow" "admin-api-write" "horizon-invalid-credentials" "user-password-reset-flow" "user-auth-flow" "user-password-update-flow" "user-profile-update-flow" Subset of named rate limiter keys to clear when ip or identifier is provided. Defaults to ALL values — specify this to avoid clearing unrelated limiters (e.g. admin ones when resetting a user flow). |
{- "ip": "127.0.0.1",
- "identifier": "user@example.com",
- "partner_code": "PARTNER01",
- "user_id": 12345,
- "limiters": [
- "admin-reset-password-email"
]
}{- "cleared": [
- "named:user-auth-flow:116.203.224.45",
- "named:user-auth-flow:user@example.com",
- "identifier-throttle:user@example.com",
- "mp-throttle:PARTNER01",
- "user-throttle:12345"
]
}