Pixel-perfect   Retina-ready   Fast   Consistent   Hackable   No tracking

Endpoint

https://img.shields.io/endpoint.svg?url=...&style=...

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 bandwidth 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.

Schema

Breaking changes to the schema will trigger an increment to the `schemaVersion`.

schemaVersion
Required. Always the number 1.
label
Required. The left text, or the empty string to omit the left side of the badge. This can be overridden by the query string.
message
Required. Can't be empty. The right text.
color
Default: lightgrey. The right color. Supports the eight named colors above, as well as hex, rgb, rgba, hsl, hsla and css named colors. This can be overridden by the query string.
labelColor
Default: grey. The left color. This can be overridden by the query string.
isError
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.
namedLogo
Default: none. One of the named logos supported by Shields or simple-icons. Can be overridden by the query string.
logoSvg
Default: none. An SVG string containing a custom logo.
logoColor
Default: none. Same meaning as the query string. Can be overridden by the query string.
logoWidth
Default: none. Same meaning as the query string. Can be overridden by the query string.
logoPosition
Default: none. Same meaning as the query string. Can be overridden by the query string.
style
Default: flat. The default template to use. Can be overridden by the query string.
cacheSeconds
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.

Customize and test

/endpoint
e.g. https://shields.redsparr0w.com/2473/monday
optional
optional
optional
optional

Copied
Copy Badge URL

Like This?

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

StatusGitHub