Creatr Ships Its Integrations Directory: 100+ Services, Wired In at Build Time

Creatr now publishes a full directory of the services it can connect to your application - and the core set is already shipped as production integrations, not roadmap promises.

The list covers the categories most products need on day one: payments, CRM, accounting, email, calendars, advertising, AI, analytics, and automation. Stripe, Zoho CRM, QuickBooks, Gmail, Outlook, Google Calendar, Outlook Calendar, Google Ads, Meta Ads, Creatr's own AI stack, email tracking, and Zapier are all built and wired in at build time. Alongside them sits a broader catalog - Slack, HubSpot, Shopify, Notion, Twilio, Salesforce, and more - that Creatr can wire into a build on request.

Why a directory, and why now

Most founders do not think in terms of "integrations." They think in terms of outcomes: charge customers, follow up with leads, send the receipt, book the meeting. Every one of those outcomes is an integration under the hood, and every one is a place where the build can stall or ship broken.

The problem is not finding the API. Documentation for Stripe, Google Calendar, and Zapier is public and thorough. The problem is everything that sits between the API call and a working production feature: the OAuth dance and what happens when the token expires at 3 a.m., the webhook that arrives twice and has to be deduplicated, the error that surfaces only when a real user has a real account with real data. AI builders and no-code tools typically stop at 60 to 70 percent - enough to demo, not enough to trust with real customers.

Creatr's integrations directory makes the surface area explicit. If the service you need is listed as "Built by Creatr," it is already handled end to end, and it has been tested against real scenarios. If it is in the wider catalog, it gets scoped into your build on request. Either way, you know before the build starts what is already solved and what will get solved.

The directory also answers a question that comes up early in almost every Creatr conversation: can you connect to X? The answer is now findable in one place, with a clear distinction between what ships immediately and what ships on request.

What "built by Creatr" actually means

The phrase "built by Creatr" is doing specific work. It is not a badge for having read the API docs. It marks integrations where Creatr has handled the production edge cases that the happy-path demo always skips.

Here is what that covers in practice.

OAuth and token lifecycle. Most integrations use OAuth. The initial authorization flow is straightforward. What breaks in production is the refresh: tokens expire, users revoke access, scopes change. For every shipped integration, Creatr manages the full token lifecycle - obtaining credentials, storing them securely, refreshing before expiry, and surfacing errors in a way the app can handle rather than silently failing.

Webhook signature verification. Services like Stripe and Zapier send event data to your app via webhooks. Before your app acts on that data - creating a record, sending an email, updating a subscription - the payload has to be verified. An unverified webhook is a security gap. Creatr's shipped integrations verify signatures before any payload is processed.

Idempotency and retries. Webhooks get delivered more than once. Payment events arrive in unexpected order. The shipped integrations handle idempotency so that a duplicate Stripe charge event does not create a duplicate transaction in your database, and retries are wired in where the external service can fail transiently.

Data flowing into the rest of the app. The integration does not stop at the API call. The data has to land somewhere - database, UI, business logic, downstream notifications. For built integrations, that wiring is scoped and built as part of the feature, not treated as a separate problem the developer has to solve after the integration "works."

End-to-end testing. The shipped integrations are tested against real accounts and real flows, not just mocked API responses. A payment flow is tested with actual Stripe test mode charges. A calendar integration is tested with real events. That is the line between an integration that demos and one that holds up when a real user hits an edge case.

The integrations that ship today

The current set of built-and-shipped integrations covers six categories.

Payments. Stripe handles one-time charges, subscriptions, and invoicing. The integration covers the full lifecycle: checkout, webhooks for payment events, subscription status changes, and the edge cases around failed charges and dunning.

CRM and accounting. Zoho CRM connects contact and deal data to the application. QuickBooks handles accounting - invoices, expenses, and financial records flowing between the app and the books.

Email. Gmail and Outlook cover the two dominant business email providers. Both are built with OAuth, so users connect their own accounts. Use cases range from sending transactional messages to reading and threading inbound replies.

Calendars. Google Calendar and Outlook Calendar handle scheduling: creating events, reading availability, and keeping the app in sync when events change.

Advertising. Google Ads and Meta Ads connect campaign data to the application. The practical use here is pulling performance data into a dashboard, or pushing conversion events back from the app to the ad platform.

AI. Creatr ships its own AI stack as a set of integrations: the Creatr AI gateway for general LLM access, Creatr AI Chat for conversational interfaces, Creatr AI Knowledge for RAG over your own documents and data, and Creatr AI Image for image generation. These are first-party integrations - built and maintained by Creatr, not proxies to a third-party service.

Analytics and automation. Email tracking provides open and click data for outbound messages. Zapier connects the app to the wider ecosystem of tools that did not make the core list.

The wider catalog, on request

Beyond the shipped set, Creatr maintains a broader catalog of services it can wire into a build. These are not speculative - they are integrations Creatr can scope, build, and test as part of a project. The request-based list includes tools like Slack for notifications and internal messaging, HubSpot for marketing and CRM workflows, Shopify for e-commerce data, Notion for document and database sync, Twilio for SMS and voice, and Salesforce for enterprise CRM.

The distinction between "shipped" and "on request" is about what is already built and tested versus what gets scoped into a specific project. Both are handled with the same production standard - the on-request integrations go through the same OAuth, webhook, and testing work as the shipped set. The difference is lead time, not quality.

How this fits how Creatr builds

Creatr's model is to take a plain-English description of an app and ship a production web app in roughly 24 to 48 hours. Integrations are not a post-launch concern in that model - they are scoped from the requirements at the start.

When a founder says "users should be able to pay monthly" or "send me a Slack message when a new lead signs up," those are integration requirements. They show up in the build plan alongside the data model, the UI components, and the auth system. By the time the app ships, the payment flow is not a stub that needs a developer to finish it - it is built, tested, and handling real transactions.

The directory makes that process more transparent. Instead of asking "can you connect to Stripe?" and waiting for an answer, you can see the answer before the conversation starts. For the shipped integrations, you know exactly what is already built and what to expect. For the request-based catalog, you know the range of what is possible.

This also matters for scoping. Integrations have a non-trivial build cost - not in API calls, but in all the production work described above. Knowing which integrations are already built versus which need to be scoped helps set accurate expectations about what a build covers and what it costs.

What's next

The directory ships with a clear boundary: integrations listed as "Built by Creatr" are production-ready today. The on-request catalog is available for any build. The plan is for more of that catalog to move into the built-and-shipped set over time as Creatr adds to the core integration library.

The direction is straightforward: more categories, more depth in existing integrations, and a continued focus on the production edge cases rather than the demo path. If a service is missing from the directory entirely, that is worth raising - the request-based model means Creatr can evaluate and build new integrations as demand warrants.

The integrations directory is live at getcreatr.com/integrations. Each integration page covers what it does, what the built version handles, and how to include it in a build.