Maintain a provider, or bring your API

1. Start from the templateomni-provider-template has a skeleton per family; bin/init <family> <service> fills the names, and its suite is green before a line is written.
2. Run the family’s conformance suiteEach core ships its suite as a PHPUnit trait (<Core>\Testing). The provider is built over recorded answers (MockHttpClient): the suite never reaches the network.
3. Prove it runs outside any frameworkTests/BareTest.php loads every class with the package’s own requirements; no framework in require, an HTTP client always accepted from outside.
4. Keep the CI greenThe skeleton’s workflows call glitchr-studio/ci, pinned to a commit: tests on each push, a release with its notes, its archive checksum and a provenance attestation on each tag.
5. Propose itOpen a “Provider” issue: the family, the service, its usage policy, what can be checked live. The name is agreed there, then the repository is created under glitchr-omnisense.

Who maintains what

• Every provider repository lives under the glitchr-omnisense organisation, MIT licensed, so that it outlives any one person’s availability.
• Each provider names its maintainer in its README and in CODEOWNERS; a company that runs the API can be a co-maintainer.
• A change is merged after the review of the family’s maintainer and a green CI that runs the conformance suite; a change to a family’s contract needs the family’s maintainer, never a provider alone.
• The README’s “Verified, and not” says what was tried against the real service and when; the catalogue shows it as it is written.
• A maintainer who steps back says so in an issue; the provider is marked “help wanted” until someone takes it over.

Propose a provider Read “Writing a provider”

1. Review your providerRead the package that calls your API: the endpoints, the errors it maps, the limits it respects. An issue or a pull request is enough.
2. Declare your usage policy as dataEach provider carries its policy as data: the access it needs, a free tier, commercial use on it, the credit to show (Policy: auth, free, commercial, attribution, credit, terms). An application reads it before it calls you, and shows your credit as you ask.
3. Co-maintain itBe named in its CODEOWNERS: your changes to the API reach the package when they ship, not when a user notices.
4. Be listedYour API gets its card in the catalogue, with your policy and a link to your terms; a reviewed provider says so.

policy:
  auth: key            # none | key | oauth | contract
  free: true
  commercial: yes      # yes | no | conditional | unclear
  attribution: required
  credit: 'Data from Example'
  terms: 'https://example.org/api-terms'

Review or declare your API See the released providers