An ISV builds a custom API that only its own model-driven app calls. The team does not want to support other developers taking a dependency on it, so it should not appear in the Web API $metadata document or in generated early-bound classes. Which setting should the team use before shipping the managed solution?
Select an answer to reveal the explanation.
Short Explanation
IsPrivate is a "do not list" sign: the API still works, but it stops showing up in the $metadata menu and in code generators. It's not a lock, though; someone who knows the name can still call it. The trap is IsCustomizable, which stops people editing your API, not finding it.
Full Explanation
Setting the IsPrivate column of a custom API to true removes the custom API from the Web API $metadata service document and prevents Dataverse code generation tools from creating classes for its messages. This signals that the publisher does not support other developers using the message, which is exactly the ISV's intent. The message still works for callers that already know its name, which is how the ISV's own app continues to invoke it, so IsPrivate is a statement about support and discoverability rather than a security boundary. IsFunction determines whether the API is an OData function called with GET or an action called with POST; it does not affect whether the API is listed in metadata. IsCustomizable is a managed property that controls whether consumers can modify or delete the component in a managed solution; setting it to false is good practice but leaves the API fully visible in metadata. The binding type of Global means the operation is not bound to a table; it changes how the operation is addressed, not whether it is advertised. Exam caveat: private messages cannot be used inside plug-ins, and security should be enforced with ExecutePrivilegeName rather than IsPrivate. Operational check: after import, request the Web API $metadata document and confirm the custom API no longer appears while the app's calls still succeed.