Pixel-perfect Retina-ready Fast Consistent Hackable No tracking
Endpoint
/endpoint?url=...&style=...Endpoint response:
{
"schemaVersion": 1,
"label": "hello",
"message": "sweet world",
"color": "orange"
}Shields response:
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 endpoint or generating SVG on your server:
- 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.
- Badge formatting is always 100% up to date. There's no need to track updates to the npm package, badge templates, or options.
- 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.
- 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.trueto 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. Only works for named logos and Shields logos. If you override the color of a multicolor Shield logo, the corresponding named logo will be used and colored.
- 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, min300. Set the HTTP cache lifetime in seconds, which should be 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
Like This?
Have an idea for an awesome new badge?
Tell us about it and we might bring it to you!