ApisKit

Make it yours

Change brand, colours, copy and images without touching the core of the code.

Turning ApisKit into your product means changing a small, well-defined set of things. The core (src/core), the framework wiring and the business logic stay untouched.

1. Identity, in one command

npm run init-product -- \
  --name "Acme" --slug acme --company "Acme Inc" \
  --company-url https://acme.com --support-email support@acme.com \
  --base-url https://app.acme.com

It rewrites src/config/product.ts (the single source of truth), the name in package.json and the URL in .env.example.

You can run it with no arguments for interactive prompts, or with --dry-run to see what would change without writing anything.

Because everything reads from product.ts, that one command changes search metadata, emails, structured data, header, footer and translated copy at once.

2. Colours

They live in src/app/globals.css, as CSS properties, defined for light and dark themes. The whole interface is painted from those tokens: there is not a single hand-written colour in the components, and a verifier enforces it.

Changing the visual brand means changing those values. You do not go component by component.

3. Copy

It lives in src/locales/es/ and src/locales/en/, one file per namespace (landing, pricing, profile, admin, support...).

Two rules:

  • Use the tokens {brand}, {company}, {supportEmail} and {baseUrl} instead of writing your name by hand. They resolve from product.ts, so when something changes no stale text is left behind.
  • Keep English and Spanish symmetric. Every key must exist in both. npm run verify:i18n checks it, and also catches a t() pointing at a key that no longer exists, which would otherwise print the raw key on screen.

4. Navigation and support categories

  • Menu labels: common.nav.* and common.sidebar.* in the language files.
  • Support categories: the SupportCategory type in src/core/entities/SupportTicket.ts, the automatic responses in the tickets route, and the category.* labels in support.json. Rename and add the ones that fit your product.

5. Pricing and credits

  • Pack names, prices and benefits: pricing.json, in both languages.
  • Stripe price IDs: wire your products and set the keys.
  • The "this action costs N credits" model is generic: adjust the amounts and what you call it.

6. Documentation

Nothing to change here. Your documentation is written from the panel, in both languages, and stored in the database.

The one thing you may want to change is the word in the address. Pages live under /documentacion/... in Spanish and /en/documentation/... in English. If your product wants different words, they appear in four places and all four must agree: the rewrite in next.config.js, hrefDeDoc in src/lib/docs/tree.ts, and the two panel previews (DocFields.tsx and DocsList.tsx).

The ones shipped are samples, not legal advice, and every page says so with a visible notice. There is a full guide on the Legal guide page.

8. Images

Replace in public/images/:

  • logo/, your logo, which product.ts points at.
  • og/, the images shown when a page is shared on social networks.

And at the root of public/, the favicons and app icons, plus the name in site.webmanifest.

The landing and pricing graphics are vector icons, so there are no illustrations to redraw.

9. Verify

npm run verify:all      # the day-to-day gate
npm run verify:release  # the full one, with browser tests
npm run build

What you should not need to touch

src/core/, meaning the domain and the ports.

If adapting your product forces you to change something there, treat it as a template defect and fix it as such, not as a patch for your case. That is what separates a foundation that lasts five years from one that rots in six months.