How to Add Custom Fields Automatically When Publishing WordPress Posts

Some links on this page are affiliate links: if you buy through them we may earn a commission, at no extra cost to you.

WordPress custom fields are post metadata stored as key/value pairs. To populate one automatically, choose the path that matches your workflow: register the metadata and send it in the REST API request, run site-specific code when a post is saved, or configure a field plugin such as ACF. For block-editor and REST workflows, the metadata must be registered with show_in_rest enabled, and the post type must support custom-fields.

Choose the right automation path

The post’s source determines where the value should be created:

#	Preview	Product	Price
1		WordPress Bible	$25.59	Buy on Amazon
2		WordPress Onder De Motorkap: WordPress aanpassen Onder De Motorkap (Dutch Edition)	$24.99	Buy on Amazon

WordPress’s built-in custom-fields panel supports manual entry, but a rule-based or API-driven value still needs code or an integration. See WordPress’s custom-fields documentation.

Make metadata available to the block editor and REST API

Register the key with the correct schema

Register metadata on the post type with a data type, whether it is a single value, and show_in_rest => true. A typical registration looks like this in a site plugin:

#1 Best Overall

WordPress Bible

$25.59

Buy on Amazon

<?php
add_action( 'init', function () {
    register_post_meta( 'post', 'source_url', array(
        'type'         => 'string',
        'single'       => true,
        'show_in_rest' => true,
        'auth_callback' => function () {
            return current_user_can( 'edit_posts' );
        },
    ) );
} );

Use the actual post-type slug instead of post when registering metadata for a custom post type. The post type must support custom-fields; otherwise, register_post_meta will not work as expected in the block editor. The Block Editor Handbook states: “Additionally, your post type needs to support custom-fields for register_post_meta function to work”. See the Meta Boxes handbook.

Expose only what the client should use

show_in_rest makes the registered key available to REST requests and responses. Set the type and single-value behavior to match the data you will actually send. A URL, identifier, or short label is usually a string; a field that legitimately has multiple values needs a different schema and storage decision.

Populate the field while creating or updating a post through REST

Put the value inside the request’s meta object

After registration and authentication, include the key under meta when calling the posts endpoint. Learn WordPress shows this request shape:

{
  "title": "New Post Title",
  "content": "New Post Content",
  "status": "publish",
  "meta": {
    "url": "https://learn.wordpress.org"
  }
}

This is a shape example, not a complete authentication recipe. The field must be registered for REST use, the request must be made by an authorized user or application, and the key in meta must exactly match the registered key. See the Learn WordPress REST API custom-fields tutorial and the REST API handbook.

Check custom post types before debugging the payload

For a custom post type, confirm that its supports declaration includes custom-fields. Also verify that the metadata registration runs on every request where the API is used; registering it only in an editor-specific code path can make the field appear to be missing from an integration.

Assign a value automatically when WordPress saves a post

Attach a handler to save_post

The save_post action runs during post saving and is the usual hook for site-specific save automation. The official reference notes that plugins, including ACF and Pods, also use this hook, so your handler should be narrowly scoped and safe to run alongside other code. See the save_post reference.

Rank #2

WordPress Onder De Motorkap: WordPress aanpassen Onder De Motorkap (Dutch Edition)

$24.99

Buy on Amazon

<?php
add_action( 'save_post', function ( $post_id, $post, $update ) {
    if ( 'post' !== $post->post_type ) {
        return;
    }

    if ( wp_is_post_autosave( $post_id ) || wp_is_post_revision( $post_id ) ) {
        return;
    }

    if ( ! current_user_can( 'edit_post', $post_id ) ) {
        return;
    }

    if ( metadata_exists( 'post', $post_id, 'source_url' ) ) {
        return;
    }

    update_post_meta( $post_id, 'source_url', 'https://example.com/source' );
}, 10, 3 );

Replace the post type, key, value, and permission rule with the requirements of your workflow. If the value comes from a form or editor-submitted request rather than a fixed rule, validate and sanitize that input and use the appropriate nonce check before writing it.

Make repeated saves harmless

Posts can be saved more than once, and a save handler can run alongside other plugins. Decide whether the field should be written every time, only when empty, or only when a particular status or transition occurs. For a single current value, an update operation is generally safer than blindly appending another row.

add_post_meta() can add another value for an existing key. Its unique argument can prevent duplicates, but uniqueness must be selected deliberately for the field’s intended behavior. Consult the add_post_meta reference.

Use ACF when editors need managed field groups

Advanced Custom Fields (ACF) provides a visual way to define named field groups instead of building the editor interface yourself. Its documentation describes REST API access for ACF fields and a field-group setting that controls REST visibility. This can suit teams where editors configure and maintain fields, while a custom plugin is often clearer for a small, fixed automation rule. Read ACF’s REST API Integration documentation for the current settings.

ACF does not remove the need to decide when a value is created, whether it is exposed through REST, or how repeated saves should behave. Treat its field names and REST settings as part of the same data contract used by your publisher or importer.

Quick Recap

Bestseller No. 1

WordPress Bible

$25.59

Bestseller No. 2

WordPress Onder De Motorkap: WordPress aanpassen Onder De Motorkap (Dutch Edition)

$24.99

Prevent the common failure modes

• The field is absent from REST responses: confirm registration runs, show_in_rest is true, the key is spelled identically, and the post type supports custom-fields.
• The API request is rejected or ignored: check authentication, the caller’s capability, the post status, and whether the registered schema accepts the value’s type.
• The value appears twice: inspect every save path and avoid unconditional add_post_meta() when the key is intended to hold one value.
• The value changes unexpectedly: determine whether your handler runs on autosaves, revisions, status changes, or subsequent editor saves, then add the relevant guards.
• A custom post type behaves differently from standard posts: verify its supports configuration and use its exact post-type slug in metadata registration and save checks.

Implementation checklist

1. Define the key, value type, and whether it is single or repeatable.
2. Choose REST publishing, save-time code, or a field plugin based on where posts originate and who maintains the rule.
3. Register the metadata with show_in_rest when the block editor or API needs it.
4. Ensure the post type supports custom-fields.
5. For REST publishing, send the value inside the request’s meta object and use an authorized client.
6. For save automation, guard against autosaves and revisions, check permissions or nonces where applicable, and limit the handler to the intended post type.
7. Choose update or uniqueness behavior so repeated saves cannot create unintended values.
8. Test creation, update, autosave, revision, and API requests separately on the site’s current WordPress and plugin versions.

Product prices and availability are accurate as of the date/time indicated and are subject to change. Any price and availability information displayed on Amazon at the time of purchase will apply.