The HTTP API is now live. For real, current endpoints see the
API reference and the interactive docs at
api.pocketsflow.com/docs. This page is
kept as background on the API’s design principles.
Design principles
The future HTTP API is expected to:- Use REST-style endpoints with predictable, resource-based URLs.
- Rely on standard HTTP methods (
GET,POST,PATCH,DELETE). - Use JSON for request and response bodies.
- Use bearer token authentication over HTTPS.
Likely resource areas
Examples of resource groups you can expect:- Products – create and manage products and pricing.
- Orders – list and inspect orders created via Pocketsflow.
- Customers – retrieve customer information and history.
- Subscriptions – manage recurring relationships and billing.
- Payouts – view payout schedules and history.
GET /v1/ordersGET /v1/orders/{order_id}GET /v1/customers/{customer_id}POST /v1/products
Authentication
The API is expected to use:- Secret API keys or tokens associated with your Pocketsflow account.
- Standard
Authorization: Bearer <token>headers.
- Store keys securely (for example, in environment variables or a secret manager).
- Rotate and scope keys according to your security needs.
Versioning
To allow the API to evolve without breaking your integrations, Pocketsflow is likely to:- Version endpoints (for example,
/v1/...). - Provide deprecation timelines for major changes.
- Avoid hard-coding assumptions about undocumented fields.
- Monitor release notes and the roadmap for API updates.
Relationship to webhooks
Webhooks and the HTTP API will be complementary:- Webhooks push events to you when something happens.
- HTTP API lets you query and sometimes mutate data on demand.
- Receive a webhook (for example,
order.created). - Use the HTTP API to fetch additional details or trigger follow-up actions.
Staying informed
To track API progress:- Follow the public Roadmap:
https://www.pocketsflow.com/roadmap - Watch for announcements in the Pocketsflow blog:
https://www.pocketsflow.com/blog