This skill should be used when the user asks to "configure a Homepage customapi widget", "map API fields in Homepage", "use dynamic-list in Homepage", or mentions Homepage Custom API widget mappings.
Install
npx skillscat add edmundmiller/dotfiles/homepage-custom-api-widget Install via the SkillsCat registry.
This skill configures Homepage customapi widgets by inspecting an API response shape and mapping its fields into the appropriate display mode (block, list, or dynamic-list) using dot notation for nested paths. It solves the problem of correctly translating arbitrary API data structures into valid Homepage widget YAML without hardcoding secrets or adding unnecessary transformation layers. Use it when configuring, mapping, or validating Homepage custom API widget configurations.
Homepage Custom API Widget
Use this skill to configure Homepage customapi widgets from an existing API response. Keep the process narrow: inspect the response shape, map fields once, and validate the YAML you change.
Core workflow
Identify the response shape.
Capture whether the API returns an object, a root array, or an object containing an array. Treat that shape as the contract that drives the widget config.Choose the display mode.
Useblockfor scalar fields,listfor paired rows, anddynamic-listfor arrays of items.blockandlistusemappingsas an array of mapping objects.dynamic-listusesmappingsas a single object withitems,name,label, and optionallimit,format, andtarget.
Map fields exactly once.
Use dot notation for nested object paths. Use array indexes only when the response is stable and the target is intentionally positional. Prefer the root-array form only when the API actually returns an array at the root.Keep transformations local.
Applyformat,remap,scale,prefix,suffix, and date options on the mapping that needs them. Avoid helper data or extra widget layers when one mapping can express the value.Handle auth and request shape explicitly.
Setusername,password,headers,method, andrequestBodyonly when the API requires them. Keep secrets in environment variables or secret files; never hard-code tokens into the widget config.Verify the rendered contract.
Re-read the widget YAML after editing and confirm each mapping still points at a real field in the observed response. If the field shape changes, update the mapping before finishing.
Mapping rules
- Use
fieldfor the source path. - Use
labelfor the display name. - Use
formatonly when the rendered type should change. - Use
additionalFieldonly indisplay: list. - Reserve
items,name,limit, andtargetfordisplay: dynamic-list. - For arrays at the root, omit
itemsand map the root directly. - For
dateandrelativeDate, set locale and style only when presentation matters.
Common shapes
- Single object response: map scalar fields with
display: block. - Nested object response: use dot paths such as
origin.name. - Array response: use
display: dynamic-listand bindname/labelto item fields. - Aggregate count: use
format: sizeon an array, string, or object when the count is what matters.
Good defaults
- Prefer the simplest display mode that fits the response.
- Prefer stable field paths over computed structure.
- Prefer explicit labels that match the dashboard vocabulary.
- Prefer environment-backed secrets over inline values.
Additional resources
- Upstream widget reference:
https://gethomepage.dev/widgets/services/customapi/ - Rebuild and inspect the live Homepage config after editing the source file that generates it.