How to Read a Human Design Chart Programmatically

The full response at a glance

Think of the API response as a machine-readable bodygraph. Every concept a Human Design reader would point to on a chart: Type, Profile, Authority, channels, gates, the four Variables arrows has a matching field in the JSON. The full response from POST /v2/charts/coordinates contains 23 named fields on the data object: a few high-level labels (Type, Profile, Strategy, Authority), several arrays (centers, gates, channels), an Activation grid mapping 13 planetary positions across two sides, and 9 thematic labels covering cognition, signature, and the four Variables arrows. Once you know which field maps to which concept, you can read a response like a bodygraph.

Here's the response shape at a glance. Every field referenced below lives at data.<field> inside this envelope.

{
  "timestamp": "2026-06-12T09:30:00.000Z",
  "success": true,
  "message": "Chart generated from coordinates",
  "errorCode": "",
  "type": "ChartResult",
  "data": {
    "type": "Generator",
    "profile": "4/6",
    "channelsShort": ["34-57", "10-20"],
    "channelsLong": [
      "The Channel of Power (34-57)",
      "The Channel of Awakening (10-20)"
    ],
    "centers": ["Sacral", "Spleen"],
    "gates": ["34", "57", "10", "20"],
    "strategy": "To Respond",
    "authority": "Sacral",
    "definition": "Split",
    "incarnationCross": "Right Angle Cross of Planning (37/40 | 9/16)",
    "signature": "Satisfaction",
    "notSelfTheme": "Frustration",
    "cognition": "Smell",
    "determination": "Hot Thirst",
    "variables": "PRR DLL",
    "motivation": "Fear",
    "transference": "Desire",
    "perspective": "Wanting",
    "distraction": "Survival",
    "environment": "Caves Selective",
    "circuitries": "Individual, Tribal",
    "activations": {
      "design":      { "sun": "34.5", "earth": "20.2", "moon": "10.1", ... },
      "personality": { "sun": "37.4", "earth": "40.4", "moon": "22.3", ... }
    },
    "birthDateUtc": "1990-06-15T12:30:00.000Z"
  }
}

Type → data.type

data.type is one of five strings: "Manifestor", "Generator", "Manifesting Generator", "Projector", or "Reflector". It's the first thing your UI should surface. Everything else in Human Design is interpreted through the lens of Type, and it determines which Strategy applies.

Type is derived from which centers are defined and how they connect. You don't have to compute it, the API returns the resolved label so you can go straight to displaying it.

Strategy → data.strategy

data.strategy is the action pattern that aligns with the chart's Type. Possible values are "To Inform" (Manifestor), "To Respond" (Generator and Manifesting Generator), "Wait for the Invitation" (Projector), and "Wait a Lunar Cycle" (Reflector).

Strategy is derived from Type, so it never contradicts it. If you display only one piece of guidance per chart, this is the field to surface.

Authority → data.authority

data.authority is the chart's inner decision-making mechanism. The seven possible values are "Emotional", "Sacral", "Splenic", "Ego", "Self-Projected", "Mental", and "Lunar". The last is unique to Reflectors.

Each Authority maps to a specific defined center. Pair Authority and Strategy in your UI to give a reader the two pieces of guidance Human Design considers most actionable.

Profile → data.profile

data.profile is a string in the form "<conscious-line>/<unconscious-line>" , for example "1/3", "4/6", or "5/1". There are 12 valid combinations.

Each line corresponds to one of the six lines of the I Ching hexagram and represents an archetype. The first number comes from the line of the Personality (conscious) Sun activation; the second from the line of the Design (unconscious) Sun activation. The API resolves both numbers and returns the formatted profile so you don't have to parse the activation grid yourself.

Definition → data.definition

data.definition is one of five strings: "Single", "Split", "Triple Split", "Quad Split", or "No Definition".

Definition describes how energy moves between defined centers, whether it flows as one continuous network or in disconnected groups. It's a handy field for personalizing UI copy: a Split chart might get a note like "you process energy in two distinct streams," while a Single chart gets "all your centers are directly connected."

Centers → data.centers

data.centers is an array of strings naming every defined center. There are nine centers in the Human Design system: "Head", "Ajna", "Throat", "G", "Ego", "Sacral", "Solar Plexus", "Spleen", and "Root". The array is empty if no center is defined; it can contain up to nine entries.

This is the field you map to your chart SVG to highlight defined centers. The full walkthrough is in How to Render an Interactive Human Design Chart with SVG and JavaScript.

Channels → data.channelsShort and data.channelsLong

There are 36 channels in Human Design, each connecting a pair of gates between two centers. The API surfaces activated channels in two parallel arrays:

• data.channelsShort: array of strings in "<gate-a>-<gate-b>" form, e.g. ["34-57", "10-20"]. Use this to drive SVG highlighting.
• data.channelsLong: the same channels with their canonical names, e.g. ["The Channel of Power (34-57)", "The Channel of Awakening (10-20)"]. Use this for tooltips, lists, and reading copy.

A channel is defined when both of its gates are activated, and gate definition is implicit in channel definition; there's no separate "defined gates" array beyond what data.gates already lists.

Gates and the Activation grid → data.gates and data.activations

data.gates is an array of strings like ["34", "57", "10", "20"]: the gate numbers activated anywhere in the chart. There are 64 gates in total, mapped one-to-one with the 64 hexagrams of the I Ching.

data.activations is a two-side object: data.activations.design (unconscious) and data.activations.personality (conscious). Each side holds 13 planetary positions: sun, earth, northNode, southNode, moon, mercury, venus, mars, jupiter, saturn, uranus, neptune, and pluto. Each value is a string in "<gate>.<line>" format, for example "34.5" means gate 34, line 5.

The string format is deliberate: parse it with a single split(".") to get the gate (left) and line (right) as numbers. Color, tone, and base, the deeper Variables grid, are not in the data response.

Incarnation Cross → data.incarnationCross

data.incarnationCross is a single string of the form "<Cross Name> (<cs>/<ce> | <us>/<ue>)" , for example "Right Angle Cross of Planning (37/40 | 9/16)". The four numbers are the conscious-Sun, conscious-Earth, unconscious-Sun, and unconscious-Earth gates.

The Incarnation Cross is the densest single-string summary of a chart's life theme.

Variables and the cognition labels

The four arrows in the bodygraph look cryptic until you know the pattern: the API breaks them into separate named fields so you can render each one without parsing anything yourself.

• data.variables: a six-letter code such as "PRR DLL" describing the four-arrow configuration (digestion, environment, awareness, perspective) across both sides. Pass it through a lookup table to resolve to long-form labels.
• data.cognition, data.determination, data.motivation, data.transference, data.perspective, data.distraction, and data.environment: each a single string label (e.g. "Smell", "Hot Thirst", "Caves Selective").
• data.signature, data.notSelfTheme, and data.circuitries: additional one-string fields. circuitries is a comma-separated list of activated circuits (e.g. "Individual, Tribal").

If you're surfacing variables in your UI, the cleanest pattern is to render data.variables as the four-arrow visual and the other labels as a short list beneath it.

Birth date → data.birthDateUtc

data.birthDateUtc is the birth date and time you supplied, normalised to UTC and returned as an ISO 8601 datetime string, for example "1990-06-15T12:30:00.000Z". It's useful for caching: store it alongside the chart so you can re-render or re-fetch without asking the user for their birth details again.

A worked example

Here is the chart payload for an anonymous Generator born 1990-06-15 at 12:30 UTC, returned from POST /v2/charts/coordinates:

{
  "type": "Generator",
  "profile": "4/6",
  "strategy": "To Respond",
  "authority": "Sacral",
  "definition": "Split",
  "centers": ["Sacral", "Spleen"],
  "channelsShort": ["34-57", "10-20"],
  "gates": ["34", "57", "10", "20"],
  "incarnationCross": "Right Angle Cross of Planning (37/40 | 9/16)",
  "signature": "Satisfaction",
  "notSelfTheme": "Frustration",
  "activations": {
    "personality": { "sun": "37.4", "earth": "40.4", "moon": "22.3" },
    "design":      { "sun": "34.5", "earth": "20.2", "moon": "10.1" }
  },
  "birthDateUtc": "1990-06-15T12:30:00.000Z"
}

A reader UI built on top of this could lead with "Generator, Strategy: To Respond, Authority: Sacral", highlight the Sacral and Spleen centers in the SVG, draw the 34-57 and 10-20 channels, and render an explainer card for the Right Angle Cross of Planning. Every value is a single field lookup, no client-side derivation needed.

FAQ

Does the API return interpretations?

No. The API returns data: labels, arrays, and identifiers. Building interpretive content (descriptions of Strategy, Authority, channels, and so on) is your add-on value.

Is the response the same on every plan?

No. The POST /v2/charts/simple endpoint is available on every plan and returns five fields: type, profile, gates, channelsShort, and centers. The full 23-field ChartResult shape documented above is returned by POST /v2/charts and POST /v2/charts/coordinates, both of which require the Developer plan or higher (€35/month).

How are activation values encoded?

Each entry in data.activations.{design,personality}.<planet> is a string in "gate.line" form, e.g. "34.5" for gate 34 line 5. Split on . to parse.

What's the difference between channelsShort and channelsLong?

channelsShort is a list of "a-b" gate-pair identifiers suitable for SVG element IDs and database keys. channelsLong is the same set with canonical channel names, better for tooltips and reading copy.

Why are some fields strings and some arrays?

Single-value fields (Type, Profile, Authority, Definition) are strings. Multi-value fields (Centers, Channels, Gates) are arrays. Activation entries are strings because each planetary position resolves to exactly one gate.line: there's no plurality to express. The shape of each field reflects how the data actually behaves, so your code can be predictable too.

Ready to inspect a real response?

Start with a Hobbyist plan for €22.50/month and call POST /v2/charts/simple today, or grab a Developer plan for the full 23-field ChartResult documented above: activations, incarnation cross, variables, and all. See pricing →

For the full request/response reference, see the quickstart and the v2 charts reference. If you're coming from Bodygraph.io or MyBodygraph and wondering whether they have a developer API, the short answer is no. Here's what developers use instead.

Background on the system itself: Human Design System (Wikipedia).