What is a public API and webhooks?
A public API exposes your platform's data and functionality to third-party developers. Instead of only operating through your own app interface, customers and partners can build integrations directly — pulling data into their own systems, automating workflows, or extending what your platform does.
Webhooks are the complementary push mechanism: rather than a third party polling your API every few minutes to check for changes, your platform proactively sends an HTTP request to their server when something happens (an order is placed, a payment succeeds, a user signs up). This is more efficient and much more responsive.
Together, they're what allows your platform to connect to Zapier, Make, or a customer's internal systems.
When does your app need it?
- Customers are asking "can we connect this to our CRM / ERP / existing tools?"
- You want your platform listed on Zapier or Make as an integration
- Partners need to build their own interfaces on top of your data
- Enterprise buyers require API access as a procurement requirement
- You're building a platform business and want to create an ecosystem around your product
- You need to receive data from third-party services in real time (webhooks inbound)
How much does it cost?
Adding a public API and webhooks typically adds 8–16 hours of development — roughly $1,000–$4,000 AUD.
Lower end: A read-only REST API for core resources, API key authentication, basic rate limiting, and minimal OpenAPI documentation. One or two webhook event types.
Higher end: Full CRUD API across multiple resources, API key management (create, rotate, revoke via dashboard), per-key rate limiting, versioning, comprehensive OpenAPI/Swagger documentation, a developer documentation site, multiple webhook events with configurable endpoints, webhook retry logic with exponential back-off, and a delivery log so customers can debug failed deliveries.
How it's typically built
The API itself is typically built on the same backend framework already in use (Express, Fastify, Next.js API routes). API keys are stored as hashed values in your database — similar to passwords — and validated on each request via middleware.
Rate limiting is applied per key using an in-memory counter or Redis to prevent abuse. Versioning (e.g. /v1/, /v2/) is implemented via URL prefix routing or request headers. OpenAPI documentation is generated from code annotations or schema definitions, and served via Swagger UI or Redoc.
Webhooks require a subscriber table (endpoint URLs per customer), a delivery queue (BullMQ or similar), retry logic for failed deliveries, and a log of recent attempts. Outbound payloads should be signed (HMAC-SHA256) so recipients can verify they came from you.
Questions to ask your developer
- Is this a public API or a private integration? Public APIs need versioning and documentation; private integrations don't.
- How will API keys be managed by customers? Self-service key management is a significant UX addition.
- What events will trigger webhooks? Each event type is discrete scope — be specific early.
- How are webhook failures handled? Retry logic and delivery logs are essential for production use.
- Do you need rate limiting per customer tier? Different plan limits require more configuration.
See also: Real-time updates · API versioning · App cost calculator