Pixel-perfect   Retina-ready   Fast   Consistent   Hackable   No tracking

Endpoint (Beta)


Endpoint response:

{ "schemaVersion": 1, "label": "hello", "message": "sweet world", "color": "orange" }

Shields response:

hello | sweet world

Developers rely on Shields for visual consistency and powerful customization options. As a service provider or data provider, you can use the endpoint badge to provide content while giving users the full power of Shields' badge customization.

Using the endpoint badge, you can provide content for a badge through a JSON endpoint. The content can be prerendered, or generated on the fly. To strike a balance between responsiveness and bandwith utilization on one hand, and freshness on the other, cache behavior is configurable, subject to the Shields minimum. The endpoint URL is provided to Shields through the query string. Shields fetches it and formats the badge.

The endpoint badge is a better alternative than redirecting to the static badge enpoint or generating SVG on your server:

  1. Content and presentation are separate. The service provider authors the badge, and Shields takes input from the user to format it. As a service provider you author the badge but don't have to concern yourself with styling. You don't even have to pass the formatting options through to Shields.
  2. Badge formatting is always 100% up to date. There's no need to track updates to the npm package, badge templates, or options.
  3. A JSON response is easy to implement; easier than an HTTP redirect. It is trivial in almost any framework, and is more compatible with hosting environments such as RunKit endpoints.
  4. As a service provider you can rely on the Shields CDN. There's no need to study the HTTP headers. Adjusting cache behavior is as simple as setting a property in the JSON response.


The schema may change during the beta period. Any changes will be posted here. After launch, breaking changes will trigger an increment to the `schemaVersion`.

Required. Always the number 1.
Required. The left text, or the empty string to omit the left side of the badge. This can be overridden by the query string.
Required. Can't be empty. The right text.
Default: lightgrey. The right color. Supports the eight named colors above, as well as hex, rgb, rgba, hsl, hsla and css named colors.
Default: grey. The left color.
Default: false. true to treat this as an error badge. This prevents the user from overriding the color. In the future it may affect cache behavior.
Default: none. One of the named logos supported by Shields or simple-icons. Can be overridden by the query string.
Default: none. An SVG string containing a custom logo.
Default: none. Same meaning as the query string. Can be overridden by the query string.
Default: none. Same meaning as the query string. Can be overridden by the query string.
Default: none. Same meaning as the query string. Can be overridden by the query string.
Default: flat. The default template to use. Can be overridden by the query string.
Default: 300, min 300. Set the HTTP cache lifetime in seconds, which should respected by the Shields' CDN and downstream users. Values below 300 will be ignored. This lets you tune performance and traffic vs. responsiveness. The value you specify can be overridden by the user via the query string, but only to a longer value.

Like This?

What is your favorite badge service to use?
Tell us and we might bring it to you!