When working with Microsoft Dataverse, you often need to look beyond the data itself and check the metadata. That includes table definitions, option sets, teams, and security roles. Whether you are troubleshooting an automation, auditing access, or preparing a new app, the Web API is the quickest way to get this information.
In this article, I’ve created a practical Dataverse Web API cheat sheet. It highlights the most common queries you will use as a developer or admin, complete with ready-to-run examples. No theory, just endpoints you can copy, paste, and try out.
A list of all standard Dataverse tables can be found here.
All Web API requests need your Dataverse Organization URL at the start of the endpoint. This URL is unique per environment. To find it:
Go to the Power Platform admin center.
Select the environment you want to connect to.
Copy the value shown under Environment URL (it looks like
https://<envname>.crm4.dynamics.com).Use this as the base for your Web API calls, adding the copy-pastable examples after it.
When to use: If you’re an admin or developer exploring all the tables (entities) available in a Dataverse environment, this query lists them along with key names. This is useful for getting the logical name, schema name, and display name of each table without opening the Dataverse designer.
Example endpoint: Use the EntityDefinitions entity set to fetch entity metadata. We select only a few properties to keep results lean (since EntityMetadata is quite large):
/api/data/v9.2/EntityDefinitions?$select=LogicalName,SchemaName,DisplayNameWhat it does: Returns a JSON array of all tables in the environment, including each table’s logical name (used in scripts/API), schema name (typically similar to logical name), and the display name (friendly name shown in the UI). This helps you quickly verify table names and confirms custom vs. standard tables. For example, you’ll see entries like Account (display name) with logical name account and schema name Account.
When to use: Ideal for app makers and developers who need to populate dropdowns or interpret choice values. Global Choices (formerly “Option Sets”) are lists of options that can be reused across tables (e.g., a list of countries or statuses). Instead of hard-coding values, you can fetch these via the API to ensure your app always uses the latest list.
Example endpoint: Query the GlobalOptionSetDefinitions entity set. We select the option set Name and expand its Options to get each option’s label and value:
/api/data/v9.2/GlobalOptionSetDefinitions?$select=Name&$expand=Options($select=Label,Value)What it does: Retrieves all global choice sets by name, each with an array of options (each option’s value and label text). The response shows the option set Name (unique name) and an Options array. Each option includes a localized Label (e.g., “Active”, “Inactive”) and its underlying Value (an integer). This is useful for building dynamic dropdowns or understanding what each value represents. (Note: You can’t filter this query to a single option set in a bulk call – the global option set endpoint doesn’t support filtering, so it returns all global choices or, if you need just one, query by its Name or MetadataId.)
When to use: For admins auditing security or developers reviewing sharing models. Access teams are teams in Dataverse used for record-level sharing (as opposed to owner teams which own records). This query fetches all teams of type Access in the environment, which helps identify teams created for specific record access.
Example endpoint: Use the teams entity set with a filter on teamtype equals 1:
/api/data/v9.2/teams?$filter=teamtype eq 1
What it does: Returns all teams where Team Type = 1, which corresponds to Access teams (For reference, Team Type 0 = Owner team, 2 = Azure AD Security Group team, 3 = Office Group team) The result includes each team’s properties like team name, ID, business unit, etc. This is a quick way to list all Access teams (often named after records or functions, depending on how they’re used) so you can review which access teams exist in your environment. It’s especially handy if you’ve enabled auto-created access teams on certain tables – those teams will show up here.
When to use: If you need to see who belongs to each team (particularly Access teams or even Owner teams), this query will list team members. This is useful for auditing team access or troubleshooting security by checking team composition without manually opening each team in the UI.
Example endpoint: Expand the team’s membership. We filter to Access teams (teamtype 1) and expand the many-to-many relationship to system users:
/api/data/v9.2/teams?$filter=teamtype eq 1&$expand=teammembership_association($select=fullname,systemuserid)What it does: For each Access team, the query returns the team record and an expanded list of its members. The teammembership_association is the navigation property linking teams and users (many-to-many). In the result, each team entry will have a teammembership_association array containing user records (we selected each user’s fullname and systemuserid). This way, you can see the members of each Access team directly in one call – great for reviewing who has access via teams. (You can also use a similar approach for owner teams by changing the filter to teamtype eq 0, or remove the filter entirely to get all teams with their members, though that could be a lot of data.)
When to use: If your environment uses auto-created access teams (a feature where Dataverse automatically creates an access team for each record of a certain table based on a template), you might want to see the templates configured. Access Team Templates define the rules for those teams (which table, what access rights, etc.). This endpoint lists all team templates in the system.
Example endpoint: Query the teamtemplates entity set:
/api/data/v9.2/teamtemplatesWhat it does: Returns all Team Template records. Each template will include details like the teamtemplateid (GUID), teamtemplatename (template name), and the objecttypecode or table it’s associated with. You can identify which tables have auto-created access teams enabled and the default access rights mask configured by looking at these templates (the JSON includes a defaultaccessrightsmask value which corresponds to permissions like read, write, etc.). This is useful for developers and consultants to verify if any entities are using access team templates and to understand their settings.
Other Handy Endpoints
Beyond the above scenarios, here are a few more quick endpoints that come in handy for Dataverse metadata and administrative queries:
Retrieve relationships: Use the
RelationshipDefinitionsentity set to get relationship metadata. For example, to list all relationship schema names in your environment:/api/data/v9.2/RelationshipDefinitions?$select=SchemaName. This returns the schema names of all relationships (1:N, N:1, N:N) defined in Dataverse. It’s helpful when you’re figuring out how tables are linked or verifying if a relationship exists.Retrieve users: List all user accounts in the environment with key info. For example:
/api/data/v9.2/systemusers?$select=fullname,domainname. This fetches each user’s full name and login name (domainname). Use it to audit active users or to get user IDs and names for scripting. You can add filters, e.g.,$filter=isdisabled eq falseto get only active users.Retrieve roles: Get a list of security roles. For example:
/api/data/v9.2/roles?$select=name,businessunitid. This returns each role’s name and the business unit it belongs to. It’s useful for quickly reviewing role names and ensuring they exist in the correct BUs (the GUID for businessunitid can be cross-referenced or expanded to get the BU name). Security auditors and admins can use this to script permission reviews.
(You can of course combine these with filters, expands, and selects as needed – for instance, expanding systemuserroles_association on systemusers to see which roles a user has, and so on. The above are starting points for common needs.)
Tips for Testing These Queries
Finally, a quick tip: you don’t have to write a full application to test these Web API calls. Here are some handy tools to try out these endpoints and see the results in a friendly format:
Postman or API clients: Tools like Postman are great for sending GET requests to your Dataverse Web API. Just set up an environment with your organization URL and OAuth token, then paste in these endpoints to see the JSON results. It’s quick for one-off checks.
VS Code REST Client extension: If you prefer using Visual Studio Code, the REST Client extension lets you write HTTP requests in a
.httpor.restfile and send them directly from VS Code. You can save a list of these queries and run them with a click – very handy for a developer’s cheat sheet.Power Automate with Custom Connectors: For a more integrated approach, consider creating a Custom Connector in Power Automate for the Dataverse API. You can then call these metadata endpoints in flows. This is useful for automating audits (e.g., a scheduled flow that lists teams or roles) or for quickly testing calls using the Flow editor (with the new HTTP action or a custom connector action).
Using these tools, you can experiment with the endpoints above, tweak queries (add $filter, $orderby, etc.), and incorporate the results into your app or governance processes. Happy querying!
