# An integrations catalog that hides credentials with nowhere to go > A SaaS integration layer with 98 registered definitions, 67 live base motors, encrypted secrets, connection checks, and no decorative credential cards. Source: https://saascode.ai/inside/integrations-cards-with-live-motors · Published: 2026-08-21 · Section: fabric --- An integrations page can lie without containing a single false logo. The card is real. The API key validates. The status turns green. But if no product code ever reads that credential, nothing has been integrated. The base takes a harder position: a card appears in the admin only when the product has a motor that consumes it. The current registry contains 98 integration definitions. The base motor registry contains 67 matching slugs. Those 67 appear in the catalog and its counts. The other 31 stay hidden. That smaller visible number is deliberate. It means the admin does not invite an owner to configure Salesforce, Mux, Notion, or another service merely because a credential form exists. A product can reveal one of those definitions after it adds the code that performs the sync, upload, transcription, or other operation. This is the difference between a catalog of possible credentials and a catalog of working product connections. ## What a live motor means The 67 base motors do different jobs, but each has a named consumer. Payment credentials are resolved by the payment layer. Email credentials are selected by the transactional sender. Notification settings feed Slack, Discord, Teams, Telegram, Twilio, Pushover, and ntfy channels. Analytics and support settings drive scripts or widgets on the application surface. Four automation cards feed the outgoing-webhook engine. CAPTCHA settings are checked on authentication forms. S3 and R2 settings select an object-storage backend. The gate does not ask whether a card looks complete. It asks whether the slug is present in the motor registry. The integrations page applies that test before it builds the visible list, category totals, or connection stats. A hidden definition therefore cannot inflate the number the owner sees. Products can extend the gate in two ways: add a slug to their static motor list or register one at application startup. Both routes make the card eligible to appear. Neither route creates the integration logic by itself. The product still has to supply the consumer that justified registering the motor. That extension path preserves useful setup metadata without turning it into a shipped claim. The hidden definitions already describe required fields, documentation links, icons, and help text. They are raw material for a product that needs them, not promises made by every product. ## One credential model, several consumers Every definition uses the same key convention. Non-secret values go to organization-scoped settings. Secret fields go to encrypted secret storage. The admin reads both sets, masks stored secrets, and builds the connected state from values that actually exist. Saving a provider does more than write form fields where the consumer needs a selected provider. Email, payments, and AI settings also update an active-provider pointer. Email setup can synchronize its sender address. This prevents a common half-configuration: valid credentials exist, but the sending or payment layer never selects them. Disconnecting follows the same relationship in reverse. A server-side operation removes the integration's settings and encrypted secrets. If that provider was active, it also removes the active pointer. Email cleanup removes the linked sender address. On a successful response, the admin moves to one explicit disconnected state instead of leaving a provider selected after its key disappeared. The four outgoing automation cards show how the layer connects to the rest of the product. Saving a Zapier, Make, n8n, or Pabbly webhook URL creates or updates a managed outgoing webhook. From then on, normal product events reach that URL through the same signed delivery path as manually configured webhooks. The card is only the configuration surface. The webhook engine is the motor. ## Connection tests are evidence, not the definition Every visible card receives a test endpoint. Some handlers make a lightweight provider call. Others validate an identifier or credential shape. A few services have no safe account probe and report that the real connection will be established on first use. That distinction matters. A successful API ping proves that a credential was accepted at that moment. A format check proves less. Neither proves that the product has a workflow that uses the service. The motor gate and the connection test answer different questions, and both are needed. The verification route reads the saved fields for the signed-in organization. Secret values are decrypted on the server for the check; they are not returned to the browser. The admin can save, verify, inspect a result, and disconnect from one surface. ## The honest limit The base does not expose all 98 registered definitions as working integrations. It exposes 67 because 31 definitions have no registered base motor. The hidden set includes CRM, project-management, media, productivity, and marketing services that a specific product may later wire. Registering a hidden slug is an extension hook, not an implementation. A product that reveals a card without adding the consuming code would defeat the rule even though the gate technically passes. Connection verification also varies by provider. Some checks contact the service; some only validate format; some defer the real answer until first use. A green format check should not be read as an end-to-end delivery test. The outgoing-automation bridge runs after settings are saved and does not roll the save back if its managed-webhook update fails. Zapier, Make, n8n, and Pabbly owners should confirm that the managed row appears in the webhooks area; a successful endpoint test alone does not prove the event subscription row exists. Disconnect cleanup is server-side and checks each database error, but its settings, secret, and active-pointer deletions are sequential rather than one database transaction. An error after an earlier deletion can leave partial cleanup even though the UI reports failure. The current path avoids a false success toast; it does not provide transactional rollback. Finally, configuration is organization-scoped, but several categories select one active provider at a time. The base supports switching; it does not promise simultaneous fan-out across every provider in a category. ## Why the gate is part of the product Most integration catalogs optimize for the largest logo wall. This one pays a visible cost for a more useful contract. Thirty-one known services stay out of the admin until there is code behind them. That decision connects the catalog to the rest of the platform. A payment card leads to checkout. An email card leads to the sender. A notification card becomes an alert destination. An automation card becomes a signed webhook. Storage and CAPTCHA settings alter real request paths. An integration is not the place where a secret is stored. It is the path from configuration to execution, with a way to test it and a clean way to remove it. The catalog only shows the paths the product can complete.