[Change] Custom Types Support in Memberships Endpoints

English Forum Developers & API Changelog
1

[Change] Custom Types Support in Memberships Endpoints

Summary

The /memberships endpoints now support Custom Task Types. You can use Custom Task Type GIDs as the parent parameter when creating, retrieving, updating, and deleting memberships. Responses for memberships belonging to a Custom Task Type include a new resource_subtype value: custom_type_membership.

Custom Task Types are reusable task configurations (e.g., “Bug ticket”, “Feature request”) that standardize how work is tracked in Asana. With this change, you can now programmatically control which teams and users have access to specific Custom Task Types in your workspace.

This is an additive, non-breaking change. Existing integrations are not affected.

Who is affected

This change is relevant to developers who:

  • Build integrations that manage Custom Task Types and need to control team or user access to them via the API.
  • Manage team-based sharing and permissions for Custom Task Types programmatically.
  • Parse membership responses and switch on resource_subtype — you should add a case for custom_type_membership to handle this new type gracefully.

Usage

Changed Endpoints

The following endpoints now accept Custom Task Type GIDs and return custom_type_membership as a resource_subtype:

Endpoint What changed
GET /memberships/{membership_gid} Returns "resource_subtype": "custom_type_membership" when the membership belongs to a Custom Task Type.
GET /memberships?parent={parent_gid} Accepts a Custom Task Type GID as the parent parameter.
POST /memberships Accepts a Custom Task Type GID as parent. Supported access_level values: admin, editor, user.
PUT /memberships/{membership_gid} Supports updating access_level for custom type memberships.
DELETE /memberships/{membership_gid} Supports deleting custom type memberships.

No new error codes have been introduced. Existing error handling applies.

Response Shape

When you retrieve a membership for a Custom Task Type, the response includes the custom_type_membership subtype. Here is an example response for a GET request:

// GET /memberships?parent=1234567890
{
  "data": [
    {
      "gid": "1122334455",
      "resource_type": "membership",
      "resource_subtype": "custom_type_membership",
      "parent": {
        "gid": "1234567890",
        "resource_type": "custom_type",
        "name": "Bug Ticket"
      },
      "member": {
        "gid": "987654321",
        "resource_type": "team",
        "name": "Engineering"
      },
      "access_level": "editor"
    }
  ]
}

This response shape applies to all GET, POST, and PUT responses involving a Custom Task Type parent.

Code examples

Add a team to a Custom Task Type

The member field accepts either a team GID or a user GID.

// POST /memberships
{
  "data": {
    "parent": "1234567890",
    "member": "987654321",
    "access_level": "editor"
  }
}

In this example, the team identified by GID 987654321 is granted editor access to the Custom Task Type identified by GID 1234567890.

Retrieve memberships for a Custom Task Type

// GET /memberships?parent=1234567890

Returns all memberships for the given Custom Task Type, each with "resource_subtype": "custom_type_membership".

Update a membership’s access level

// PUT /memberships/1122334455
{
  "data": {
    "access_level": "user"
  }
}

Delete a membership

// DELETE /memberships/1122334455

Removes the membership, revoking the member’s access to the Custom Task Type.

Timeline

These endpoints are now live for all organizations.

Resources

2 Likes