Namespace: dmyip/v1
The dmyip/v1 REST API exposes the same date rendering as the shortcodes, publicly and read-only, so headless frontends and external tools can fetch the exact values the plugin would render in WordPress.
All endpoints are public (no authentication required). Since 1.8.0 they’re always available: the plugin loads through Composer when present, with a PSR-4 fallback for source installs.

GET /wp-json/dmyip/v1/dates
Returns all date types organized by category.
Response:
{
"year": {
"current": "2026",
"next": "2027",
"previous": "2025"
},
"month": {
"current": "February",
"current_short": "Feb",
"next": "March",
"previous": "January",
"number": "2"
},
"day": {
"current": "18",
"weekday": "Tuesday",
"weekday_short": "Tue"
},
"combined": {
"date": "February 18, 2026",
"monthyear": "February 2026",
"next_month": "March 2026",
"prev_month": "January 2026"
},
"events": {
"blackfriday": "November 28",
"cybermonday": "December 1"
},
"season": {
"north": "Winter",
"south": "Summer"
},
"timezone": "America/New_York",
"timestamp": 1771372800,
"date_format": "F j, Y",
"time_format": "g:i a"
}GET /wp-json/dmyip/v1/date/{type}
Returns a single date value.
Path parameter:
type(required) – Any supported date type
Query parameters:
offset(int, optional) – Signed year or month offset, capped at ±1000date(string, optional) – Target date for countdown/age types (YYYY-MM-DD, or MM-DD for recurring types)rule(string, optional) – Recurring rule for occurrence types, likelast sunday of januaryformat(string, optional) – PHP date formatcase(string, optional) – Output case:none,title,upper,lowerrollover_day(int, optional) – Switch month output to the next month after this daylocale(string, optional) – Render in a specific locale
Supported types: year, nyear, nnyear, pyear, ppyear, month, month_short, month_number, month_number_zero, nmonth, pmonth, date, monthyear, nmonthyear, pmonthyear, day, weekday, weekday_short, published, modified, blackfriday, cybermonday, daysuntil, dayssince, age, age_ym, age_ymd, age_ordinal, season, season_south, nextoccurrence, daysuntilnext, occurrenceyear
Since 1.8.0 this endpoint validates against canonical type names, not shortcode aliases. Use month_short instead of mon, day instead of dt, weekday_short instead of wd, and published/modified instead of datepublished/datemodified. Countdown, age, and occurrence types return a 400 error when the required date or rule is missing or invalid.
Examples:
GET /wp-json/dmyip/v1/date/year
→ {"type": "year", "value": "2026", "timezone": "America/New_York"}
GET /wp-json/dmyip/v1/date/year?offset=5
→ {"type": "year", "value": "2031", "timezone": "America/New_York"}
GET /wp-json/dmyip/v1/date/month
→ {"type": "month", "value": "February", "timezone": "America/New_York"}
GET /wp-json/dmyip/v1/date/daysuntil?date=2026-12-25
→ {"type": "daysuntil", "value": "310", "timezone": "America/New_York"}
GET /wp-json/dmyip/v1/date/age?date=1990-05-15
→ {"type": "age", "value": "35", "timezone": "America/New_York"}
GET /wp-json/dmyip/v1/date/daysuntilnext?date=01-01
→ {"type": "daysuntilnext", "value": "158", "timezone": "America/New_York"}
GET /wp-json/dmyip/v1/date/season
→ {"type": "season", "value": "Winter", "timezone": "America/New_York"}GET /wp-json/dmyip/v1/shortcodes
Returns a categorized catalog of representative shortcodes. Since 1.8.0 the response is a flat list of shortcode strings per category:
{
"year": ["[year]", "[year n=\"5\"]", "[nyear]", "[pyear]"],
"month": ["[month]", "[mon]", "[nmonth]", "[pmonth]"],
"date": ["[date]", "[monthyear]", "[weekday]", "[datepublished]", "[datemodified]"],
"countdown": ["[daysuntil date=\"YYYY-MM-DD\"]", "[dayssince date=\"YYYY-MM-DD\"]", "[age date=\"YYYY-MM-DD\" format=\"ymd\"]"],
"events": ["[blackfriday]", "[cybermonday]", "[season]", "[season region=\"south\"]"]
}GET /wp-json/dmyip/v1/render
Added in 1.8.0. Renders exactly one plugin shortcode and returns its value. Only tags on the plugin’s internal allowlist are accepted; anything else returns a 400 error, so the endpoint can’t be used to render arbitrary shortcodes.
Query parameter: shortcode (required), a single complete shortcode string.
GET /wp-json/dmyip/v1/render?shortcode=[year]
→ {"shortcode": "[year]", "value": "2026"}
GET /wp-json/dmyip/v1/render?shortcode=[age date="1990-05-15"]
→ {"shortcode": "[age date=\"1990-05-15\"]", "value": "35"}Usage from JavaScript
// Fetch all dates
const response = await fetch('/wp-json/dmyip/v1/dates');
const dates = await response.json();
console.log(dates.year.current); // "2026"
console.log(dates.month.current); // "February"
console.log(dates.season.north); // "Winter"
// Fetch a specific date type
const age = await fetch('/wp-json/dmyip/v1/date/age?date=1990-05-15');
const data = await age.json();
console.log(data.value); // "35"
// Fetch with year offset
const futureYear = await fetch('/wp-json/dmyip/v1/date/year?offset=10');
const result = await futureYear.json();
console.log(result.value); // "2036"Usage from cURL
# All dates
curl https://example.com/wp-json/dmyip/v1/dates
# Single date
curl https://example.com/wp-json/dmyip/v1/date/year
# Age calculation
curl "https://example.com/wp-json/dmyip/v1/date/age?date=1990-05-15"
# Days until event
curl "https://example.com/wp-json/dmyip/v1/date/daysuntil?date=2026-12-25"
# List all shortcodes
curl https://example.com/wp-json/dmyip/v1/shortcodesQuick answers to common questions:
Why are the endpoints public?
They return computed dates, not site data, so there’s nothing to protect: the same values any visitor sees rendered in your content. Public access is what makes headless and JavaScript use cases work without auth plumbing.
When would I actually use the REST API?
Headless WordPress builds that need consistent date rendering with the backend, external dashboards displaying countdowns, and integration tests verifying shortcode output. For PHP contexts, the shortcodes and functions are simpler.