Skip to main content
A listing is one folder in TableProApp/integrations: an integration.json manifest, a 512x512 icon.png and up to four screenshots. If you publish the integration, open the pull request yourself. If you only use it, open a Suggest an integration issue instead, and the maintainers ask the author before listing it.

Before you start

  • You own the repository, belong to the organization that owns it, or are a major contributor. Anyone else needs the owner’s consent in a comment on the pull request.
  • The integration calls only the surfaces on Build an integration, finds TablePro by bundle ID, and reads none of TablePro’s private files.
  • The repository has a LICENSE file with an SPDX license, or the entry is closed source and shows a Closed source label.
  • The product name follows <Name> for TablePro, and the icon is your own. The brand guidelines list the name forms.
  • It works with the current TablePro release.

Add the entry

1

Fork the registry

Fork TableProApp/integrations and create integrations/<slug>/. The slug is 2 to 40 characters of lowercase words joined by hyphens, without tablepro. It becomes the page address, tablepro.app/integrations/<slug>, and never changes after the first merge.
2

Write the manifest

Add integration.json. Start from the sample, from a listed entry like yours, or from the test fixtures. Keep the $schema line: an editor that reads JSON Schema completes and checks every field.
3

Add the images

icon.png is a 512x512 PNG of at most 512 KB. SVG is refused. Screenshots are optional: up to four 1600x1000 PNGs of at most 1 MB each, named screenshot-1.png upward without gaps, and each listed under screenshots with alt text.
4

Run the validator

From the root of your fork, with Python 3.10 or later:
The /usr/bin/python3 that Xcode and its command line tools install is 3.9, and the pinned requirements do not install on it. Install a newer Python, for example with brew install python, and create the environment with that one.
The summary line reports 0 errors.
5

Open the pull request

One entry per pull request, titled feat(<slug>): add <Name>. Fill in the checklist in the template, and link the owner’s consent comment if you need one.

Sample manifest

A fictional launcher command that lists connections over AppleScript and opens one with a tablepro:// link. It passes the validator as written.
integrations/example-launcher/integration.json

Manifest fields

schema/integration.schema.json is the full reference. This table covers what it leaves to you. Both numeric IDs come from the GitHub API:

Disclosures

The entry page shows these under What it uses. The listing policy treats a wrong one as a violation.

What the checks look at

Every pull request runs Registry Gate, the one required check. A failure appears as an annotation on the line in Files changed, and the run summary lists each error. Push a fix to the same branch. The checks cover:
  • The manifest against the schema, and the text: normalized to NFC, with no emoji and no invisible characters.
  • The name and slug, against reserved words and the other entries.
  • The folder: only the manifest, the icon and the listed screenshots, at the right sizes. An icon that looks like the TablePro app icon fails.
  • Every link: https, no IP address or URL shortener, and it answers.
  • The GitHub IDs: githubId belongs to the login, repoId is the repository in repo, and that repository is public and not archived.
  • The license GitHub detects in the repository, against license. In a monorepo, or when GitHub cannot identify the license, a maintainer checks it by hand.
  • Who opened the pull request. Anyone other than the publisher, the repository owner or a public member of its organization gets a needs owner consent label, which a maintainer removes once the owner consents or your commits show you are a major contributor.
  • The install target: the store page, release, formula or cask has to exist.
  • The source: CI fetches the repository and searches its text files for the paths of TablePro’s private files. A match fails the check with its file and line. A fetch that fails leaves only a warning.
  • The scope: one entry folder per pull request, and no file outside it.
Run without flags, the validator skips every check that needs the network: the GitHub IDs, the license, who opened the pull request, links answering, the install target and the source scan. CI runs them all.

Change or remove an entry

To update an entry, change the files in its folder and open a pull request. The same checks run. slug and addedAt never change. tier, compliance, lastVerifiedAt, source.repoId and publisher.githubId change only in a maintainer’s pull request, so after a repository rename, update source.repo and keep repoId. To take an entry down, open a Request removal or archive issue. A pull request that deletes the folder fails the checks. An archived entry keeps its page with a notice. A removed one answers 410 Gone, and its slug is never used again.