WordPress Custom Fields REST API

Field Forge provides a full REST API for custom fields. Field values are exposed on standard WordPress REST endpoints (so /wp-json/wp/v2/posts/123 returns custom fields alongside core data), plus dedicated Field Forge endpoints for field group management, options pages, and advanced operations. Authentication uses WordPress’s existing REST API auth.

Two ways to access custom fields

1. Inline on core REST endpoints

When Field Forge is active, every wp/v2/posts, wp/v2/pages, and wp/v2/{custom_post_type} response includes a fieldforge property containing the custom field values:

GET /wp-json/wp/v2/posts/123

{
  "id": 123,
  "title": { "rendered": "About Us" },
  "content": { "rendered": "..." },
  "fieldforge": {
    "hero_title": "Welcome to Our Site",
    "hero_subtitle": "Building better WordPress experiences",
    "hero_image": {
      "id": 456,
      "url": "https://example.com/hero.jpg",
      "alt": "Hero image",
      "sizes": {
        "thumbnail": "https://...",
        "medium": "https://...",
        "large": "https://..."
      }
    },
    "team_members": [
      {
        "name": "Alice Johnson",
        "photo": { "id": 234, "url": "...", "alt": "Alice" },
        "bio": "Alice is..."
      },
      {
        "name": "Bob Smith",
        "photo": { "id": 235, "url": "...", "alt": "Bob" },
        "bio": "Bob is..."
      }
    ]
  }
}

This is how most headless WordPress sites consume custom fields — fetch a post, get custom fields in the same response, no extra requests needed.

2. Dedicated Field Forge endpoints

For advanced use cases, Field Forge exposes its own REST API under /wp-json/fieldforge/v1/.

Endpoint reference

Field groups

GET    /wp-json/fieldforge/v1/field-groups
GET    /wp-json/fieldforge/v1/field-groups/{id}
POST   /wp-json/fieldforge/v1/field-groups
PUT    /wp-json/fieldforge/v1/field-groups/{id}
DELETE /wp-json/fieldforge/v1/field-groups/{id}

List, read, create, update, and delete field groups. Use cases: headless admin panels, programmatic field group setup, CI/CD schema deployment.

Field values

GET    /wp-json/fieldforge/v1/fields/{post_id}
PUT    /wp-json/fieldforge/v1/fields/{post_id}

Get all field values for a specific post, or update them. The GET response matches the format returned in the core REST API’s fieldforge property.

Example:

GET /wp-json/fieldforge/v1/fields/123

{
  "post_id": 123,
  "field_group": "hero-section",
  "values": {
    "hero_title": "Welcome",
    "hero_image": { "id": 456, "url": "..." }
  }
}

Options pages

GET    /wp-json/fieldforge/v1/options/{page_slug}
PUT    /wp-json/fieldforge/v1/options/{page_slug}

Read and update options page values. Perfect for headless sites that need site-wide settings (company name, social URLs, global CTAs).

Schema metadata

GET    /wp-json/fieldforge/v1/schema
GET    /wp-json/fieldforge/v1/schema/typescript
GET    /wp-json/fieldforge/v1/schema/graphql

Fetch the full Field Forge schema as JSON, or as TypeScript definitions, or as GraphQL SDL. Use in frontend build pipelines to keep types in sync automatically.

Migration and import

POST   /wp-json/fieldforge/v1/import/acf
POST   /wp-json/fieldforge/v1/import/meta-box
POST   /wp-json/fieldforge/v1/import/cmb2

Trigger imports from source plugins via API. Useful for CI/CD setup scripts.

AI generation

POST   /wp-json/fieldforge/v1/generate

Body:

{
  "description": "Hero section with title, subtitle, background image, and CTA button"
}

Returns a generated field group ready to save. Use in custom admin tools or automation workflows.

Authentication

Field Forge’s REST API uses WordPress’s native authentication mechanisms:

Cookie authentication (logged-in users)

If the request comes from a logged-in WordPress user (e.g., your admin panel making AJAX calls), the user’s cookies authenticate the request automatically.

Application passwords (headless frontends)

WordPress 5.6+ supports application passwords — per-user API credentials that can be generated in the WordPress admin under Users → Edit → Application Passwords. Use these for headless frontend authentication:

curl -u username:application_password https://wp.example.com/wp-json/fieldforge/v1/field-groups

JWT authentication (third-party plugin)

If you use a JWT auth plugin (like “JWT Authentication for WP REST API”), Field Forge’s endpoints accept JWT tokens automatically.

OAuth 2.0

For enterprise use, Field Forge’s endpoints are compatible with WordPress OAuth 2.0 server plugins.

Capability checks

REST endpoints respect WordPress capabilities:

Read operations (GET): require read capability (typically any logged-in user)
Write operations (POST, PUT, DELETE) on fields: require edit_post capability on the target post
Field group CRUD: require manage_options capability (administrators only)
Import/migration: require manage_options capability

You can filter these with standard WordPress capability hooks if you need different permission models.

Pro field values on WP REST API

Field Forge exposes field values on core WordPress REST endpoints as a fieldforge property. This is the recommended approach for headless frontends because:

One request fetches post data + custom fields (no N+1 problem)
Standard REST API format — no learning curve
Works with WordPress REST API clients (wp-rest-api client libraries in JS, PHP, Python, etc.)
Compatible with static site generators (Next.js getStaticProps, Astro getStaticPaths, etc.)

For most headless sites, the fieldforge property on core REST endpoints is all you need. Dedicated Field Forge endpoints are for advanced use cases.

Performance on REST API

REST API responses benefit from Field Forge’s custom table storage and batch loading. A single REST query fetching a post + custom fields runs in 1–2 SQL queries instead of 20+.

For list endpoints (/wp/v2/posts?per_page=20), Field Forge’s auto-preloader batches custom field queries across all 20 posts into a single query, keeping response times fast even for content-heavy list views.

Combining with GraphQL

Field Forge supports both REST API and WPGraphQL integration. Use whichever fits your frontend:

REST API — simpler, works with any HTTP client
GraphQL — more efficient for deeply nested queries, better type safety when combined with GraphQL Code Generator

Both APIs expose the same underlying Field Forge data.

Ready to go headless with WordPress custom fields?

Get Field Forge — from $35/year →

The REST API is included in every paid plan. Field values on core REST endpoints are in the free version too.

REST API — Expose Custom Fields to Headless Apps