# Plugin RPC API Documentation

**URL:** <https://discuss.hashicorp.com/t/plugin-rpc-api-documentation/6074>\
**Category:** Plugin Development\
**Created:** [February 19, 2020, 8:31pm UTC](https://discuss.hashicorp.com/t/plugin-rpc-api-documentation/6074 "2020-02-19T20:31:08Z")\
**Posts on this page:** 11\
**Page:** 1

<div class="post-metadata">

**Author:** ![schlitzered](https://sea2.discourse-cdn.com/hashicorp/user_avatar/discuss.hashicorp.com/schlitzered/32/4758_2.png) [@schlitzered](https://discuss.hashicorp.com/u/schlitzered)\
**Post date:** [February 19, 2020, 8:31pm UTC](https://discuss.hashicorp.com/t/plugin-rpc-api-documentation/6074/1 "2020-02-19T20:31:08Z")

</div>

Hi,

the documentation states that plugins are mostly written in go, and that terraform uses some kind of RPC api to communicate with the plugin, which i translate to, i can write a plugin in whatever language.

is there an documentation on this API? because i would like to write a plugin using python.

kind regards.

---

<div class="post-metadata">

**Author:** ![kpfleming](https://sea2.discourse-cdn.com/hashicorp/user_avatar/discuss.hashicorp.com/kpfleming/32/3376_2.png) [@kpfleming](https://discuss.hashicorp.com/u/kpfleming)\
**Post date:** [February 19, 2020, 9:00pm UTC](https://discuss.hashicorp.com/t/plugin-rpc-api-documentation/6074/2 "2020-02-19T21:00:46Z")

</div>

The documentation also says that no, the RPC API is not documented, and implementing in another language would be very challenging 🙂

---

<div class="post-metadata">

**Author:** ![schlitzered](https://sea2.discourse-cdn.com/hashicorp/user_avatar/discuss.hashicorp.com/schlitzered/32/4758_2.png) [@schlitzered](https://discuss.hashicorp.com/u/schlitzered)\
**Post date:** [February 20, 2020, 8:00am UTC](https://discuss.hashicorp.com/t/plugin-rpc-api-documentation/6074/3 "2020-02-20T08:00:37Z")

</div>

and i guess there are no active plans to document it?

---

<div class="post-metadata">

**Author:** ![kpfleming](https://sea2.discourse-cdn.com/hashicorp/user_avatar/discuss.hashicorp.com/kpfleming/32/3376_2.png) [@kpfleming](https://discuss.hashicorp.com/u/kpfleming)\
**Post date:** [February 20, 2020, 5:44pm UTC](https://discuss.hashicorp.com/t/plugin-rpc-api-documentation/6074/4 "2020-02-20T17:44:05Z")

</div>

I haven’t seen anything from HashiCorp indicating that, and based on what they have published I suspect it’s unlikely as it would increase their maintenance burden substantially.

---

<div class="post-metadata">

**Author:** ![paddy](https://sea2.discourse-cdn.com/hashicorp/user_avatar/discuss.hashicorp.com/paddy/32/4484_2.png) [@paddy](https://discuss.hashicorp.com/u/paddy)\
**Post date:** [February 20, 2020, 8:48pm UTC](https://discuss.hashicorp.com/t/plugin-rpc-api-documentation/6074/5 "2020-02-20T20:48:06Z")

</div>

Hey there,

Currently, our RPC for the SDK is using gRPC. If you look around in [https://github.com/hashicorp/terraform](https://github.com/hashicorp/terraform) a bit, you can find the protobuf files describing the protocol. There are also some docs on the protocol and resource lifecycles.

I’m being intentionally vague about this because right now the only support we offer is for building providers with our [Go SDK](https://github.com/hashicorp/terraform-plugin-sdk). The technical ability for providers to be written in Python exists, but the support structures for it–places to ask questions, well-defined documents making it easy, communication channels tailored to developers operating at the protocol level, and tooling to support it–do not. Provider developers could, in theory, write a Python provider, but I would strongly encourage not doing that.

While we’re not closing the door on implementing providers in other languages, at the moment we’re focused on ensuring the developer experience with our Go SDK is up to our expectations. Other languages is a thing we’re keeping in the back of our minds, but it’s not something we’re actively investigating supporting at this time.

---

<div class="post-metadata">

**Author:** ![nfx](https://sea2.discourse-cdn.com/hashicorp/user_avatar/discuss.hashicorp.com/nfx/32/10100_2.png) [@nfx](https://discuss.hashicorp.com/u/nfx)\
**Post date:** [November 24, 2020, 2:14pm UTC](https://discuss.hashicorp.com/t/plugin-rpc-api-documentation/6074/6 "2020-11-24T14:14:41Z")

</div>

> [@paddy](#):
>
> While we’re not closing the door on implementing providers in other languages, at the moment we’re focused on ensuring the developer experience with our Go SDK is up to our expectations. Other languages is a thing we’re keeping in the back of our minds, but it’s not something we’re actively investigating supporting at this time.

I think it’s just harder to manage installation of plugins written in non-compiled languages.

---

<div class="post-metadata">

**Author:** ![schlitzered](https://sea2.discourse-cdn.com/hashicorp/user_avatar/discuss.hashicorp.com/schlitzered/32/4758_2.png) [@schlitzered](https://discuss.hashicorp.com/u/schlitzered)\
**Post date:** [November 24, 2020, 5:34pm UTC](https://discuss.hashicorp.com/t/plugin-rpc-api-documentation/6074/7 "2020-11-24T17:34:58Z")

</div>

it is all about options.

providing a proper documentation would help externals devs to implement there own SDK i am currently trying to reverse engineer how the plugin API works, so i can implement a python based SDK. but it is a time consuming task :-/

---

<div class="post-metadata">

**Author:** ![SSSOCPaulCote](https://sea2.discourse-cdn.com/hashicorp/user_avatar/discuss.hashicorp.com/sssocpaulcote/32/28883_2.png) [@SSSOCPaulCote](https://discuss.hashicorp.com/u/SSSOCPaulCote)\
**Post date:** [September 13, 2022, 2:03pm UTC](https://discuss.hashicorp.com/t/plugin-rpc-api-documentation/6074/8 "2022-09-13T14:03:29Z")

</div>

Hey, how far along did you get with this idea? I’m running into a similar situation where I’d like the `go-plugin` library to properly support non-go plugins and may need to create my own SDK

---

<div class="post-metadata">

**Author:** ![teneko](https://sea2.discourse-cdn.com/hashicorp/user_avatar/discuss.hashicorp.com/teneko/32/30740_2.png) [@teneko](https://discuss.hashicorp.com/u/teneko)\
**Post date:** [October 11, 2022, 6:04am UTC](https://discuss.hashicorp.com/t/plugin-rpc-api-documentation/6074/10 "2022-10-11T06:04:11Z")

</div>

I would also be interested in introducing Terraform Plugins to the .NET world. But I think I have to go the hard way just like Paddy described by reading the source code, not very optimal.

EDIT:

What I can say so far, that this is pretty helpful as it describes how to implement the gRPC server:

> **[terraform/docs/plugin-protocol at main · hashicorp/terraform](https://github.com/hashicorp/terraform/tree/main/docs/plugin-protocol)**
>
> main/docs/plugin-protocol

Next it is important to understand how the MessagePack-encoded data structures are looking like:

> <https://github.com/hashicorp/terraform/blob/main/docs/plugin-protocol/object-wire-format.md>

Another thing to consider is to make your provider debuggable. Therefore you need to checkout:

> **[Plugin Development - Debugging Providers | Terraform by HashiCorp](https://www.terraform.io/plugin/debugging#running-terraform-with-a-provider-in-debug-mode)**
>
> How to use both logs and debugging tools to debug Terraform providers.

Keep in mind that for windows the environment variable must look something like this (I didn’t find this resources on the same page):

```auto
{
    "registry.terraform.io/example_organization/example_provider": {
        "Protocol": "grpc",
        "Pid": 17940,
        "Test": true,
        "Addr": {
            "Network": "tcp",
            "String": "127.0.0.1:50727"
        }
    }
}

```

And last but not least it is helpful when you already have implemented a provider with [GitHub - hashicorp/terraform-plugin-go: A low-level Go binding for the Terraform protocol for integrations to be built on top of.](https://github.com/hashicorp/terraform-plugin-go) as it makes use of everything I just described above.

If you are interested in taking part into a C# implementation of a fully fledged Terraform Plugin SDK, please take a look at [GitHub - pseudo-dynamic/PseudoDynamic.Terraform.Toolset: Implement Terraform plugins with best C# manners](https://github.com/pseudo-dynamic/PseudoDynamic.Terraform.Toolset).

---

<div class="post-metadata">

**Author:** ![maxb](https://sea2.discourse-cdn.com/hashicorp/user_avatar/discuss.hashicorp.com/maxb/32/26655_2.png) [@maxb](https://discuss.hashicorp.com/u/maxb)\
**Post date:** [October 11, 2022, 7:31am UTC](https://discuss.hashicorp.com/t/plugin-rpc-api-documentation/6074/11 "2022-10-11T07:31:19Z")

</div>

I’ve never used it myself, but have you seen [GitHub - SamuelFisher/TerraformPluginDotNet: Write Terraform providers in C#.](https://github.com/SamuelFisher/TerraformPluginDotNet) ?

---

<div class="post-metadata">

**Author:** ![teneko](https://sea2.discourse-cdn.com/hashicorp/user_avatar/discuss.hashicorp.com/teneko/32/30740_2.png) [@teneko](https://discuss.hashicorp.com/u/teneko)\
**Post date:** [October 11, 2022, 9:02am UTC](https://discuss.hashicorp.com/t/plugin-rpc-api-documentation/6074/12 "2022-10-11T09:02:54Z")

</div>

Maybe this the wrong topic to write this down but the implementation you are talking about @maxb, is not yet finished sadly. It does not cover all kind of complexity terraform provides you to express objects including nested blocks, objects, list and and more. [terraform-plugin-go](https://github.com/hashicorp/terraform-plugin-go) uses **[go-cty](https://github.com/zclconf/go-cty)** as example and so I do with introducing a proper type system: therefore I translate first C# classes to [my type system](https://github.com/pseudo-dynamic/PseudoDynamic.Terraform.Toolset/tree/735b2f6932b09ba9ebdc504b1e226759f560c13a/src/PseudoDynamic.Terraform.Plugin.Sdk/Schema/TypeDependencyGraph) and then to [MessagePack representation](https://github.com/hashicorp/terraform/blob/main/docs/plugin-protocol/object-wire-format.md) and back, similiar to [terraform-plugin-framework/types](https://github.com/hashicorp/terraform-plugin-framework/tree/main/types) or [terraform-plugin-go/tftypes](https://github.com/hashicorp/terraform-plugin-go/tree/main/tftypes).

The implementation you are talking about skips this step so the mapping class need to be written in view of MessagePack. Therefore the mapping classes need first to comply with MessagePack conventions and then additionally with Terraform MessagePack data format conventions which is tough. Another story are unknown values which are currently not representable by this implementation.

So I can only repeat myself: If you are interested in taking part into a C# implementation of a fully fledged Terraform Plugin SDK, please take a look at [GitHub - pseudo-dynamic/PseudoDynamic.Terraform.Toolset: Implement Terraform plugins with best C# manners](https://github.com/pseudo-dynamic/PseudoDynamic.Terraform.Toolset). It still needs development time, so any help is appreciated. 😃
