Integrate your systems directly with IbaadU's B2B marketplace — automate product feeds, order management, and PRQ workflows via REST API.
IbaadU provides a REST API that enables third-party developers, enterprise technology teams, and integration partners to connect their systems directly with our B2B marketplace platform. The API supports product catalog management, order processing, PRQ submission and retrieval, vendor profile management, and real-time messaging.
Whether you are building an ERP integration, an automated procurement tool, a logistics management system, or a custom analytics dashboard, the IbaadU API gives you programmatic access to the platform's core functionality.
Standard HTTP-based RESTful API with JSON responses. Supports all major programming languages and frameworks including Python, Node.js, PHP, Java, and .NET.
Secure API key authentication for all endpoints. Keys are generated from your vendor or procurer dashboard and can be rotated at any time.
Real-time event webhooks for new orders, PRQ responses, KYC status updates, and payment confirmations. Push-based notifications to your endpoint URL.
| Endpoint | Method | Description | Auth |
|---|---|---|---|
| /api/v1/products | GET, POST | List and create product listings | API Key |
| /api/v1/products/{id} | GET, PUT, DELETE | Manage individual products | API Key |
| /api/v1/orders | GET | Retrieve order history | API Key |
| /api/v1/orders/{id} | GET, PATCH | Get/update order status | API Key |
| /api/v1/prqs | GET, POST | Browse and submit PRQs | API Key |
| /api/v1/prqs/{id}/quotes | POST | Submit a quote on a PRQ | API Key (Vendor) |
| /api/v1/vendor/profile | GET, PUT | Manage vendor profile | API Key (Vendor) |
| /api/v1/vendor/inventory | GET, POST | Bulk inventory management | API Key (Vendor) |
| /api/v1/messages | GET, POST | Read and send messages | API Key |
| /api/v1/webhooks | GET, POST, DELETE | Manage webhook subscriptions | API Key |
Connect IbaadU with SAP, Oracle, Microsoft Dynamics, or any ERP system. Automate purchase order creation when a PRQ is accepted, synchronize product inventory in real time, and push order status updates back to your internal systems without manual data entry.
For enterprise clients with large procurement volumes, API integration reduces processing time by up to 80% compared to manual portal workflows.
Maintain your IbaadU product listings in sync with your internal catalog system. Use the Products API to push bulk price updates, availability changes, and new SKU additions from your warehouse management system or product information management (PIM) tool.
Webhooks notify your system in real time when a product receives an inquiry or order, enabling instant fulfillment workflows.
Pull structured order and performance data from IbaadU into your business intelligence tools such as Power BI, Tableau, or Looker. Track vendor sales trends, average PRQ response times, conversion rates, and revenue by category and geography.
Connect IbaadU orders with your shipping and logistics providers. When an order is confirmed, automatically trigger shipment booking, generate shipping labels, and update tracking information back to the buyer via our order status API.
| Plan | Requests/Hour | Webhooks | Bulk Endpoints | Price |
|---|---|---|---|---|
| Free (Developer) | 100 | 1 | No | Free |
| Growth | 1,000 | 5 | Yes | Contact us |
| Enterprise | Unlimited | Unlimited | Yes | Contact us |
The IbaadU API is currently in Developer Preview. To request access, email admin@ibaadu.com with the subject line "API Access Request." Include your company name, the systems you wish to integrate, expected request volumes, and a brief description of your use case. Our technical team will review your request and respond within three business days.
Approved developers receive API credentials, access to our API documentation portal, and dedicated technical support during the integration phase. Full API documentation, including code samples in Python, JavaScript, PHP, and cURL, is provided upon approval.
All API requests must be made over HTTPS. The API uses JSON encoding for both request bodies and responses. Authentication is via bearer token in the Authorization header. Request/response formats follow REST conventions with standard HTTP status codes (200 OK, 201 Created, 400 Bad Request, 401 Unauthorized, 404 Not Found, 429 Rate Limited, 500 Internal Server Error).
Webhook payloads are delivered as HTTP POST requests with JSON bodies to your specified endpoint URL. Endpoints must return HTTP 200 within 10 seconds or the delivery will be retried up to three times with exponential backoff.
The IbaadU API is built on a modern, scalable architecture using RESTful HTTP standards. All endpoints return structured JSON responses. The API is served over TLS 1.3 with HTTP/2 support for optimal performance. Our infrastructure uses Supabase as the backend database layer, with row-level security (RLS) policies ensuring data isolation between accounts.
Authentication uses JWT (JSON Web Token) bearer tokens with a 24-hour expiry. Tokens are obtained through the /auth/token endpoint using your API key and secret. Long-lived refresh tokens allow automated systems to maintain access without manual re-authentication. All API keys can be revoked instantly from your account dashboard.
The Products API provides full CRUD (Create, Read, Update, Delete) capabilities for your product catalog. The GET /api/v1/products endpoint returns a paginated list of your active and draft products with full metadata. Use the fields query parameter to request only the fields you need, reducing response size. Use cursor-based pagination via the after parameter for efficient large-dataset traversal.
Creating a product (POST /api/v1/products) requires at minimum: name, category_id, price, currency_code, unit, and moq. Optional fields include description, images (array of URLs), max_quantity, lead_time_days, origin_country, brand, and specifications (key-value object). Prices should be submitted in the vendor's local currency — the API stores both the original currency and a USD equivalent for search/sort purposes.
Bulk product creation is available via POST /api/v1/products/bulk, which accepts an array of up to 500 product objects. This endpoint is rate-limited to 5 calls per minute and requires the Growth or Enterprise API plan. Responses include a batch job ID that can be polled for status via GET /api/v1/jobs/{id}.
The Orders API allows you to retrieve, filter, and update orders. GET /api/v1/orders returns your complete order history with filtering options for status, date range, buyer country, and order value. Each order object includes all line items, shipping information, invoice reference, and status history with timestamps.
Order status can be updated by vendors via PATCH /api/v1/orders/{id}/status. Valid status transitions are: confirmed → in_production → dispatched → delivered. Dispatching an order requires a tracking_number and carrier_name to be provided in the request body. When an order is marked as dispatched, the buyer receives an automatic notification with tracking details.
The PRQ API gives vendors programmatic access to the purchase request board. GET /api/v1/prqs returns all open PRQs matching your account's verified categories. Filter by category, country, posted_after date, and estimated_value_min/max. Each PRQ object includes the full specification text, quantity requirements, delivery deadline, and any certification requirements.
Submit a quote on a PRQ via POST /api/v1/prqs/{id}/quotes. Required fields: unit_price, currency_code, quantity (must be ≥ PRQ minimum quantity), lead_time_days, and incoterm. Optional: special_terms, certifications array, and message. Quotes cannot be modified after submission — if you need to revise a quote, contact the procurer via the messaging API.
IbaadU webhooks deliver real-time event notifications to your specified endpoint URL. Register a webhook via POST /api/v1/webhooks with your endpoint_url and a list of event types you wish to subscribe to. Supported events include: order.created, order.status_changed, order.delivered, prq.created (new PRQ matching your categories), prq.quote_accepted, message.received, kyc.status_changed, and payout.processed.
Webhook payloads include an event_type field, a timestamp, and an event_id for idempotency checking. We recommend storing processed event_ids and ignoring duplicate deliveries (which can occur due to network retries). Endpoints that consistently fail to return HTTP 200 within 10 seconds will be disabled after 10 consecutive failures — monitor your endpoint availability to avoid missed events.
The Python SDK (ibaadu-python) provides a high-level client for all API operations. Install via pip: pip install ibaadu. Initialize the client with your API key and secret. The SDK handles token refresh automatically, implements retry logic with exponential backoff for rate limit errors, and provides both synchronous and async (asyncio) interfaces.
The Products namespace provides list(), create(), update(), delete(), and bulk_create() methods. The Orders namespace provides list(), get(), update_status(), and get_invoice() methods. The PRQ namespace provides list(), get(), and submit_quote() methods. Full type hints and comprehensive docstrings are included for IDE autocompletion.
The Node.js SDK (@ibaadu/client) is an ESM-compatible package supporting both CommonJS require() and ES module import. It provides Promise-based and callback-based interfaces. The SDK is compatible with Node.js 16+ and can be used in browser environments with the BROWSER=true flag (which disables server-only features such as webhook signature verification).
Never expose your API key and secret in client-side JavaScript, mobile apps, or public repositories. Store credentials in environment variables or a secrets management system such as AWS Secrets Manager, HashiCorp Vault, or Azure Key Vault. Rotate API keys every 90 days as a security best practice.
All API requests should be made server-side. If you need to call the API from a browser or mobile app, implement a backend proxy endpoint that authenticates the user and makes API calls on their behalf using server-stored credentials. IbaadU's API includes CORS restrictions that will block unauthenticated browser-to-API calls.
Implement webhook signature verification for all incoming webhooks. Each webhook delivery includes an X-IbaadU-Signature header containing an HMAC-SHA256 signature of the payload body using your webhook secret. Verify this signature before processing the event to protect against replay attacks and spoofed payloads.
| HTTP Status | Error Code | Description |
|---|---|---|
| 400 | INVALID_REQUEST | Request body or parameters are malformed or missing required fields |
| 401 | UNAUTHORIZED | Invalid or expired authentication token |
| 403 | FORBIDDEN | Authenticated but insufficient permissions for this resource |
| 404 | NOT_FOUND | The requested resource does not exist |
| 409 | CONFLICT | Resource state conflict (e.g., quote already submitted) |
| 422 | VALIDATION_ERROR | Request is well-formed but contains invalid field values |
| 429 | RATE_LIMITED | Rate limit exceeded; retry after the value in Retry-After header |
| 500 | INTERNAL_ERROR | Server error; retry after a short delay; contact support if persists |
When designing your IbaadU API integration, a key architectural decision is whether to use synchronous request-response patterns or asynchronous webhook-driven patterns. For user-triggered actions — such as a user clicking "Check Inventory" or "Get Latest Orders" in your application — synchronous API calls are appropriate. Your application makes a GET request to IbaadU's API and displays the response immediately.
For event-driven workflows — such as automatically creating a purchase order in your ERP when a PRQ quote is accepted, or updating stock levels when a product sells — asynchronous webhook patterns are significantly more efficient. Instead of polling our API every few minutes to check for changes (which wastes rate limit budget and adds unnecessary latency), webhooks push event notifications to your endpoint the moment an event occurs.
We recommend a hybrid architecture: use synchronous API calls for user-initiated actions and dashboard data, and use webhooks for all background automation workflows. This gives your users the responsiveness they expect while keeping your integration infrastructure efficient and scalable.
In distributed systems, network failures can cause uncertainty about whether a request was successfully processed. If your POST /api/v1/orders request times out before receiving a response, you cannot be certain whether the order was created or not. Making a second identical request might create a duplicate order.
IbaadU's API supports idempotency keys for all POST and PATCH requests. Include an Idempotency-Key header with a unique string (we recommend a UUID generated per request attempt). If you retry a request with the same Idempotency-Key within 24 hours, the API returns the original response without processing the request again. This guarantees that retries are safe and duplication-free.
For endpoints that return lists of resources (products, orders, PRQs), IbaadU uses cursor-based pagination rather than offset-based pagination. Cursor-based pagination is more efficient for large datasets and avoids the "page drift" problem where items shift between pages during a paginated traversal due to new insertions. Request the first page without an after parameter; each response includes a next_cursor field that you pass as the after parameter in the next request. Continue until next_cursor is null.
For large catalog syncs (e.g., downloading your full product catalog), we recommend requesting pages of 100 items (the maximum page size) and processing them in parallel where possible. A catalog of 1,000 products can be fully synced in approximately 2 seconds with 10 parallel requests of 100 items each, compared to 10 seconds with sequential single requests.
IbaadU API versions are named sequentially: v1, v2, etc. Each major version introduces breaking changes — for example, renamed fields, changed response structures, or removed endpoints. We commit to maintaining each major version for a minimum of 24 months after a new major version is released, giving integration partners ample time to migrate.
Non-breaking changes (new optional fields, new endpoints, new filter options) are introduced within the current version without a version increment. We publish a changelog at api.ibaadu.com/changelog with all changes, including deprecation notices at least 6 months in advance of any removal.
Version deprecation notices are also communicated via email to all API key holders. We recommend subscribing to our API status page at api.ibaadu.com/status for real-time information about API availability, maintenance windows, and incident updates.
All API access applicants receive credentials for both the production environment and a sandbox environment. The sandbox environment is a complete replica of the production API with sample data — it includes pre-populated product catalogs, vendor profiles, buyer accounts, open PRQs, and order history. You can test all API endpoints, webhooks, and integration flows in the sandbox without affecting real data or incurring real transaction processing.
The sandbox is reset weekly (every Sunday at 00:00 GST) to maintain clean baseline data. Any data you create in the sandbox will be cleared in the weekly reset. For integration testing that requires persistent test data across the weekly reset cycle, contact our developer support team to request a dedicated sandbox environment that resets on a longer schedule.
The sandbox base URL is sandbox.api.ibaadu.com. All endpoints, authentication mechanisms, and response formats are identical to production. Webhook events are delivered to your registered test endpoints. SMTP email sending is disabled in the sandbox — email-triggered notifications appear in a sandbox email log accessible via GET /sandbox/email-log.
IbaadU's API is actively developed, with new capabilities added on a regular release cycle. The following recent additions and upcoming changes are relevant for integration partners planning their builds.
Version 1.3 (released April 2026) introduced bulk product creation via the /products/bulk endpoint, webhook signature verification using HMAC-SHA256, cursor-based pagination across all list endpoints replacing the previous page/offset model, and expanded PRQ filter parameters including posted_after, category, and estimated_value range. This version also deprecated the legacy /orders/search endpoint in favor of filter parameters on GET /orders — the legacy endpoint will be removed in v1.5, scheduled for July 2026.
Version 1.4 (planned June 2026) will introduce a vendor analytics endpoint returning product view counts, inquiry rates, and conversion metrics for the last 30/90/365 days. It will also introduce a messages API for reading and sending in-platform messages, enabling CRM integration scenarios where customer service teams can respond to procurement inquiries from within their existing tools. OAuth 2.0 authorization code flow will be added as an authentication option alongside the existing API key flow, enabling partner applications to act on behalf of users who grant explicit consent.
API key authentication using Base64-encoded credentials in the Authorization header (introduced in v1.0) is deprecated as of v1.3 and will be removed in v2.0 (planned Q4 2026). All integrations should migrate to JWT bearer token authentication before this date. The migration requires a single change: instead of encoding your API key and secret as Base64 in the Authorization header, make a POST request to /auth/token with your credentials in the request body to obtain a JWT, then include that JWT as a Bearer token in subsequent requests. The JWT auto-refresh mechanism is documented in our migration guide available in the API developer portal.
IbaadU was purpose-built for the realities of Middle East B2B wholesale commerce — not adapted from a consumer marketplace or a Western procurement tool. Our platform reflects the trading practices, regulatory environment, currency diversity, and sourcing patterns that are specific to GCC-based buyers and their global supplier networks. This regional focus, combined with our commitment to verification, transparency, and fair dispute resolution, makes IbaadU the natural choice for serious B2B trade professionals in the region.
Our free registration model is not a temporary promotional offer — it is a permanent platform policy. We believe that access to a global B2B marketplace should not be gated by high subscription fees that favor established players and exclude the emerging-market SME suppliers who bring the most competitive pricing and product innovation. By keeping core features permanently free, IbaadU ensures that the best products and the most competitive vendors can always be found on our platform, regardless of their marketing budget.
For more information about any aspect of IbaadU's platform, policies, or services, visit ibaadu.com, email admin@ibaadu.com, or speak with our team at +971 4 832 2447.
Use IbaadU to structure B2B supplier discovery, procurement requests, and vendor onboarding workflows.
Register as Vendor Register as Procurer