Aller au contenu principal

API v2 - Explanation and valid values for some fields on Tenant and User entities. Accessibility of JSON schemas.

Thread needs solution
Beginner
Contributions: 5
Commentaires: 1

On API v2 there are some fields on the Tenant and User entities for which there's no explanation available or a list of valid values to put in them. Next, the list of those fields.

  • Tenant:
    • customer_type: explanation and possible values required.
    • language: on this one I'd just like to know what type of locale ISO codes go there ("en" style, "en-US" style or maybe both?).
    • owner_id: explanation required.
    • internal_tag: explanation and possible values required.
    • default_idp_id: explanation needed, specially because it always seems to be the same value (11111111-1111-1111-1111-111111111111).
  • User:
    • personal_tenant_id: explanation required.
    • idp_id: the same comment as for default_idp_id in Tenant.
    • language: the same comment as for language in Tenant.
    • business_types: explanation and possible values required.

Related to this, I've noticed in the RAML documentation the mention to references of the json schemas for some fields like the ones I've listed before. For instance, I've read something like this:

"business_types": { "$ref": "../_common/types/business_types.json" }

That reference can be found in the request body schema of the User POST method. How could I access those json schemas?

0 Users found this helpful
Acronis Program Manager
Contributions: 7
Commentaires: 166

Hi Eduardo,

 

I understand your concern. We are constantly working on improving the documentation, however I would ovoid using this forum as a substitution to the documentation and explaining all fields that are not clear. Please provide your usage scenario, and I'll name the fields that you require.

However, I recommend to do the following when you are not sure which values to use for specific fields:

  • Create the object via common interface (Web Console)
  • Get the default values for these objects
  • Replace only those values that you need. The rest should remain as default.

 

I will comment those fields that I believe you can use in your integration. For example, an existing tenant would show: 

"customer_type":"default" << leave as is
"language":"en" << use this format, e.g. "es", "fr"
"owner_id":null << leave as is
"internal_tag":Null << leave as is
"default_idp_id":"11111111-1111-1111-1111-111111111111" << leave as is

Except for language, all other fields are internal or have been added for future functionality (like using external Identity Providers for default_idp_id).

 

For user entity:

"personal_tenant_id":null << Null for administrators, ID for service users to link a tenant with personally assigned services. Each service user will have a corresponding tenant.
"idp_id":"11111111-1111-1111-1111-111111111111" << leave as is
"language":"en" << use this format, e.g. "es", "fr"
"business_types":[] << leave as is

 

As for JSON schemas, AFAIK they are not available for public.

 

BR,

Beginner
Contributions: 0
Commentaires: 1

Dmitry Zelensky wrote:

However, I recommend to do the following when you are not sure which values to use for specific fields:

  • Create the object via common interface (Web Console)
  • Get the default values for these objects
  • Replace only those values that you need. The rest should remain as default.

As for JSON schemas, AFAIK they are not available for public.

 

Hi,

Please don't take this the wrong way, but this is no way for any of us to develop an API to sell your products for you! 

We really shouldn't have to be prodding and poking the system to try and find the values we need, it should be properly documented.  It's incredibly frustrating having to guess at everything, especially with APIv2 and makes everything take 10x longer than it should.

At the end of the day, we're here because we want to help sell your products and make you and us some money, you really should be making a better job of facilitating that with your API and documentation.  If the API is expecting values from us, we should know the schema for those values

 - if it's private, then it shouldn't be in the API and exposed at all.

 - if it's essential to make it work, then it should be documented and available to us.

Apologies for digging an old thread, but given this one was asking for the same information that I'm trying to find, it seems appropriate.

Thanks,

Karl